Centos – Two ways to lock a password but only one to unlock

centospasswdpasswordshadow

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?

Best Answer

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

Related Question