Description of problem: After installing the Cyrus-imapd RPM, I attempted to change the password for the new system user 'cyrus' so that I could use it as a cyradm root. No matter what I tried in system-config-users, the password wouldn't change. The instant I performed the password change at the command line with passwd, everything worked as expected. The conclusion I arrived at is that system-config-users doesn't work for changing passwords of users with a uid lower than 500. If this assumption is accurate, then there should be a warning appear when I attempted to do that. Version-Release number of selected component (if applicable): not shown How reproducible: Always Steps to Reproduce: 1. see above 2. 3. Actual results: password for system user not changed although no indication was given that the operation wasn't successful Expected results: Either the password should change or a warning given that it wasn't or couldn't be changed Additional info:
After a quick glance it seems that it rather cannot cope with accounts that are locked (i.e. "*" in the pw column of /etc/apsswd or /etc/shadow).
In this case, it should also show (on the Account Info tab) that the password is locked and grey out the password fields when editing the accounts. I've implemented that piece of code in s-c-users, but unfortunately libuser doesn't report correctly whether a user is locked or not (it always reports that it is unlocked). Forwarding this to the libuser component.
Created attachment 106204 [details] small python script that exposes the problem in libuser This script shows how libuser thinks the root and bin users are locked or not (root is normaly not locked, bin is). This is with libuser-0.52.5-1: nils@gibraltar:~/test> sudo ./libuser_lockedusertest.py user with uid 0 is locked: 0 user with uid 1 is locked: 0
First, I can't reproduce the original problem on FC-3 (the useradd call in cyrus-sasl is the same as in FC-2): the 'cyrus' user has '!!' as a shadow password and can be unlocked, relocked and assigned a password. Regarding the locking confusion: "locked" really means "can be unlocked", i.e. "starts with '!'". The accounts with '*' as shadow password are not really "locked"; the stored value matches no existing password hash; this usually indicates (for users like 'bin') that login as this user should never be possible. In fact, the only users with '*' as shadow passwords are the users contained in /etc/password from the 'setup' package. [And although I know almost nothing about cyrus, I have some doubts about the necessity to allow logins as the 'cyrus' user.] That said, the 'hash must be valid in order to change passsword' check is a) somewhat arbitrary b) policy that IMHO doesn't belong in libuser c) just a hassle for applications, which can bypass it by calling modifyUser with manually computed password hashes. I'll remove the check for setpass* (but not lock/unlock) in the next libuser version.
Let me ask differently, can I (i.e. can s-c-users) check for an account which is set to "*" instead of "!!"? Thus I could do some "this is a system account which shouldn't have a password yadda yadda" stuff.
... through libuser that is.
# python >>> import libuser >>> a = libuser.admin() >>> e = a.lookupUserByName('bin') >>> print e[libuser.SHADOWPASSWORD] ['*'] >>> print e.get(libuser.SHADOWPASSWORD) ['*'] The exact condition for skipping the entry is "entry is not empty && entry does not start with '!' && entry is shorter than 11 characters". As noted in comment #4, this check won't be enforced for setpass*.
Check removed in libuser 0.53-1.
Taking this back to s-c-users. Miloslav, do you think it would be more sensible to treat ":*:"-locked accounts the same as ":!....:" locked ones or differently?
AFAICT ":*:" accounts are not "locked". It could be useful to warn the user before setting ("changing") a password of such an account that doing that might not be a good idea. On the other hand accounts like "sync", "shutdown", "halt" are meant to have a password, so the warning could have a non-trivial amount of false positives. My choice would be to do nothing special, but I don't feel strongly about it.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Closing per lack of response. Also note that FC1 and FC2 are no longer supported even by Fedora Legacy. If this still occurs on FC3 or FC4, please assign to that version and Fedora Legacy. If it still occurs on FC5 or FC6, please reopen and assign to the correct version.