Logical issue with creating users with passwords and updating passwords for users on Linux

[Moritz Heiber]

Currently, I believe there is a logical issue with the way passwords are treated for users that are created using the user resource:

The :create action needs the password parameter to be in plain text, since it's passed verbatim to useradd by the run_specinfra call. However, on subsequent runs, the password parameter is expected to be the encrypted password, since the code is using the :get_encrypted_password call for run_specinfra and the :update_encrypted_password call to re-set it if they don't match.

Therefore you end up with an unusable states on subsequent runs when the user resource is being used to set a password with the same data supplied to the run.

My proposition would be either of these two scenarios:

1. Accept the password parameter for the user resource to be plain text only and use appropriate hashing mechanisms to encrypt it on the fly (with proper detection for the algorithm being used). I wouldn't prefer this since it's less secure, and it's also a lot of assumptions and potentially unportable code.
2. Accept the password parameter for the user resource to only be a valid shadow hashed entry. There are tons of hash validation libraries out there, with the most common even built-into Ruby itself. This would also be more secure than having to specify a plain text password for a run, and it's also comparable to what Chef does.

It cannot be both, it needs to be a single value, and it should be the secure alternative.