Two ways to lock a password but only one to unlock

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

Let me explain this to you

The differnce is that linux has two ways to lock an user's login :

1- by locking the password

2- by locking the username

First:

passwd -l test < this will lock the password for user.

passwd -u test < the locked password can only be unlocked by this, means only then user can login.

Second:

usermod -L test < this will lock the username for user.

usermod -U test < the locked username can only be unlocked by this, means only then user can login.

Note:

you can not unlock the password of a user which is locked by "passwd" utility with "usermod" utility and vice-versa.

Answer 4

"you can not unlock the password of a user which is locked by "passwd" utility with "usermod" utility and vice-versa."

Someone posted above information..

It is not true, the account that locked using usermod command can be unlocked using passwd -u command..

Account locked using passwd -l command can be unlocked using usermod -U command (need to execute twice)..

Answer 5

Looks like this is fixed in CentOS 7,able to achieve unlock using any command irrespective of the method of lock

++Someone mentioned that these 2 commands do different things-one locks password whereas other locks user account,NOT true: passwd -S (username) will display LK in both scenarios(usermod -L (username) AND passwd -l (username) )

Lock user account uing: chage -E 0 (username)