Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
user.present with hash_password: True detects change on every state.apply/highstate #45939
Description of Issue/Question
user.present with hash_password: True detects change on every highstate. The password is successfully set to what was intended, but upon subsequent highstates, salt always thinks it needs to change the root password again.
Steps to Reproduce Issue
Run state multiple times against same node. The password is set successfully without error, but always detects a change is necessary.
Minions and masters all running same version. Tested on 2017.7.2 and 2016.11.2
Also not working on:
@andygabby Thanks for the report. Looking at the code for this I can see why it's continuously attempting to set the password. When
@garethgreenaway Thanks for the reply! I noticed the same about shadow.gen_password. Setting enforce_password: False kind of defeats the purpose of changing the pillar for pushing password updates.
shadow.gen_password can take a crypt_salt argument so that if passed the same value each time, would give you a consistent hash of the same password.
Perhaps the user state/module could take crypt_salt as an argument to pass to shadow.gen_password so a consistent salt value could be used to hash the password?
For some of us using encrypted pillars, there are use cases where it may not be desirable or needed to gen a password, hash it, then encrypt the hash for the pillar
I have the same problem and tried to find a solution: If salt get plain passwd and the current password with correct hash function is stored on the system, salt can compare it by combining the plain password and the stored salt. If the result between this new hash and the stored hash, salt can set a new password. I think, all needed information are available.
I tried to extend salt to do it.
Sorry for my bad python skils, but maybe it's for anyone usable.
This diff is working for me on this system in this folder:
referenced this issue
Apr 18, 2018
added a commit
Apr 18, 2018
@eliasp Your solution looks good for me, but you will reuse the same password salt if you change the password. I would expect from states.user.present that a new salt is generated if the password is changed. I think, that can become a security issue.
I think, it's better to reuse the salt only for compare the passwords