Red Hat Bugzilla – Bug 131180
system-config-users doesn't warn it can't change system passwords
Last modified: 2008-08-02 19:40:33 EDT
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):
Steps to Reproduce:
1. see above
password for system user not changed although no indication was given
that the operation wasn't successful
Either the password should change or a warning given that it wasn't or
couldn't be changed
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
[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'
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"
... through libuser that is.
>>> 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.