CentOS 6 Linux has two ways to lock a password:
passwd -l
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 andpasswd
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 befoo
orMr. Spock
.Also note this comment under the
--lock
flag inpasswd(1)
on Linux: