Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

CentOS 6 Linux has two ways to lock a password:

  1. passwd -l
  2. usermod -L

Today I found out, that they do something different.

passwd writes two exclamation marks into the shadow file.

# passwd -d test1
Removing password for user test1.
passwd: Success
# passwd -l test1
Locking password for user test1.
passwd: Success
# passwd -S test1
test1 LK 2014-01-14 0 99999 7 -1 (Password locked.)
# grep test1 /etc/shadow
test1:!!:16084:0:99999:7:::

But usermod writes only one.

# passwd -d test1
Removing password for user test1.
passwd: Success
# usermod -L test1
# passwd -S test1
test1 LK 2014-01-14 0 99999 7 -1 (Password locked.)
# grep test1 /etc/shadow
test1:!:16084:0:99999:7:::

Is this only a cosmetic inconsistency or is there a meaning for the different lock indicators?

Funny things happen, if you mix the two commands:

Lock an account with passwd:

# passwd -l test1
Locking password for user test1.
passwd: Success

Unlock it with usermod:

# usermod -U test1

And surprise it is still locked:

# passwd -S test1
test1 LK 2014-01-14 0 99999 7 -1 (Password locked.)

Bug or feature?

share|improve this question
    
I haven't tried it, but when using passwd -l to lock it, then can't you use usermod -U twice to unlock it? –  Wilf Jan 14 at 19:35
    
This has already been reported: bugzilla.redhat.com/show_bug.cgi?id=951743 –  ceving Jan 21 at 13:35

2 Answers 2

It doesn't matter. The behavior you're seeing is implementation specific. That's why usermod does one thing and passwd does something else. They're different implementations. See what happens on Solaris, AIX, HP-UX, True64, Xenix...

The password field is a crypted or hashed string. When the user supplies a password it is crypted or hashed according to the algorithm specified in the password field. The authentication is only successful if both the supplied and stored crypted/hashed forms match.

A single ! or a double !! can never match any crypted password. In other words there is no input that will ever crypt to the result value ! or !!. Any string that could never be the hash result will "lock" the account. It may as well be foo or Mr. Spock.

Also note this comment under the --lock flag in passwd(1) on Linux:

Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970).

share|improve this answer
    
I was asking from the distribution point of view. If Red Hat ships an operating system with two tools for the same job, which are incompatible, this sounds at least as a distribution bug. –  ceving Jan 15 at 9:01

This sounds like a bug but is likely completely cosmetic, so long as you stay with one tool or the other, just not both! If you take a look at the shadow man page (man 5 shadow) it has this to say about the password field (On CentOS).

   encrypted password
       Refer to crypt(3) for details on how this string is interpreted.

       If the password field contains some string that is not a valid result
       of crypt(3), for instance ! or *, the user will not be able to use a 
       unix password to log in (but the user may log in the system by other 
       means).

       This field may be empty, in which case no passwords are required to 
       authenticate as the specified login name. However, some applications 
       which read the /etc/shadow file may decide not to permit any access 
       at all if the password field is empty.

       A password field which starts with a exclamation mark means that the 
       password is locked. The remaining characters on the line represent 
       the password field before the password was locked.

This last paragraph would make the issue sound like it's an implementation bug in the passwd command, since a single (!) is all that is needed to lock a password.

Digging deeper

One thing that bothered me with the above potentiality of this being a bug is that I can't imagine it would've persisted for this long. The other thing that bothered me with this is that in my /etc/shadow file I have lines like the following:

abrt:!!:16047::::::
openvpn:!!:16047::::::
unbound:!!:16047::::::

So searching a bit more I did come across this article titled: Understanding /etc/shadow file. In the comment section of this article is the following bit:

lesca September 23, 2010 at 4:29 am
!! means user account has not been initialed or has not been locked.
! means group password is not available.
* means login disabled.

This last bit jogged my memory enough to remember that in the not too distant past there used to be group passwords as well as user passwords. You can read more about them in this blog post titled: Linux Set or Change User Password as well as the replaced functionality gpasswd in this blog post titled: A group password in Linux.

At any rate I believe you have found a bug! The bug is in the passwd command.

share|improve this answer
    
Actually, from that last paragraph, it sounds like !! is a bug. –  derobert Jan 14 at 20:02
    
@derobert - maybe, or that ! is part of the hash? –  slm Jan 14 at 20:10
1  
Well, "before the password was locked"... so it sounds like locking should add a single ! in front. Adding two sounds like a bug (especially since it actually causes problems when you unlock with the other tool...) –  derobert Jan 14 at 20:11
    
@derobert -agreed, if the ! was there prior then it's part of the hash, otherwise 2 of them afterwards looks to be a bug in the tool. –  slm Jan 14 at 20:15
    
@derobert - revised my answer. –  slm Jan 14 at 20:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.