Bug 131180 - system-config-users doesn't warn it can't change system passwords
system-config-users doesn't warn it can't change system passwords
Product: Fedora
Classification: Fedora
Component: system-config-users (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
Depends On:
  Show dependency treegraph
Reported: 2004-08-28 08:24 EDT by Marc Williams
Modified: 2008-08-02 19:40 EDT (History)
2 users (show)

See Also:
Fixed In Version: 0.53-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-25 16:34:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
small python script that exposes the problem in libuser (183 bytes, text/plain)
2004-11-05 05:24 EST, Nils Philippsen
no flags Details

  None (edit)
Description Marc Williams 2004-08-28 08:24:50 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):
not shown

How reproducible:

Steps to Reproduce:
1. see above
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:
Comment 1 Nils Philippsen 2004-09-15 09:20:38 EDT
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).
Comment 2 Nils Philippsen 2004-11-05 05:21:57 EST
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.
Comment 3 Nils Philippsen 2004-11-05 05:24:50 EST
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
Comment 4 Miloslav Trmač 2004-11-07 09:25:07 EST
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.
Comment 5 Nils Philippsen 2004-11-08 16:19:33 EST
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"
Comment 6 Nils Philippsen 2004-11-08 16:19:59 EST
... through libuser that is.
Comment 7 Miloslav Trmač 2004-11-08 16:28:24 EST
# 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*.
Comment 8 Miloslav Trmač 2004-11-14 17:55:01 EST
Check removed in libuser 0.53-1.
Comment 9 Nils Philippsen 2004-11-15 05:13:16 EST
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?
Comment 10 Miloslav Trmač 2004-11-15 05:23:29 EST
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.
Comment 11 Matthew Miller 2005-04-26 12:27:10 EDT
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.
Comment 12 John Thacker 2006-10-25 16:34:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.