As far as I understand, different implementations had different ways to specify the semantics of “disabling the account”. So the developers of the passed command went to look for details that would be un-ambiguous in all implementations, and this seems to be what they found:
- neither an asterisk nor an exclamation mark in the first character of the password hash file alone can be unambiguously interpreted as “disabling the account”, because there are conflicting implementations - however, setting the account expiration date to a non-null value that is in the past was found to be a totally unambiguous way to disable an account without losing any account details that might be under user’s (limited) control, like the user’s shell setting. - setting the account’s shell to a non-usable value should not be the only way to mark the account as “no logins of any type allowed”, since there are plenty of valid use cases for accounts with a valid shell but logins disabled. So the resulting password/account management options relevant to this discussion after all was said and done are now: - an exclamation mark in the first (or only) character of the password hash field = a (possibly-temporary) administrative lock on password authentication for his user. *Can be unlocked* without changing the existing password, even if the existing password is null. - an asterisk as the first (or only) character of the password hash field = a (possibly-permanent) lock on password authentication. Undoing this with standard commands requires setting a new password, or an explicit decision to set a null password. - a non-null “account expiration date” value that is not 0 and is in the past = account is disabled. This can (and probably should) be used together with one of the previous options when creating an application account that should never have an ability to login, but is usable with sudo or a similar mechanism. As a result, the —disabled-login option of the adduser command won’t do what it claims to do, if authentication mechanisms other than password authentication are in use. Example: if the sysadmin uses “adduser --disabled-login” to create an application user account, and an attacker manages to fool the application into writing a valid ~/.ssh/authorized_keys file, it turns out that the supposedly-disabled account now allows SSH key authenticated login for the attacker. This is unexpected. The fix: “adduser --disabled-login" needs to perform an explicit “usermod --expiredate 1” or equivalent in addition to what it does now. After the changes made to the passwd command in 2008, “passwd -l” will no longer do that for you.
