Linux locked accounts and PAM

[Dan Yefimov]

On Wed, 8 Oct 2008, Max Bowsher wrote:

> > Password hash entry is implicitly checked at pam_authenicate() time, not at 
> > pam_acct_mgmt() time. But pam_authenticate() is not called during public key 
> > authentication. That's exactly what I said.
> 
> No, you're missing something: A password hash that begins with a !
> character, by mostly undocumented but fairly widespread convention, has
> a meaning beyond mere authentication - it denotes a completely locked
> account. This semantic is expected by traditional Linux tools such as
> those built from the 'shadow' source package of most Linux distros, and
> extended tools such as Debian's 'adduser', which makes a distinction
> between a disabled *account* and a disabled *password* and maps this to
>  the "!" vs. "*" convention.

No, I miss nothing here. Whatever prefix password hash begins with, if 
the password hash derived from the string obtained from the user isn't equal to 
what is contained in shadow, access is denied, no matter why. Prefix 
differences among different systems is unimportant here.

> > SSHD rejects such accounts while performing password verification. If the 
> > password hash for password provided by user isn't equal to what is contained in 
> > shadow, access is denied. That's simple. I think there is no reason to 
> > duplicate the job of auth stack compulsorily, but if somebody wants such 
> > duplication, let him specify special pam_unix command line option in account 
> > stack.
> 
> This isn't about password verification, or duplication of anything. It
> is about implementing the semantics for the password hash field that I
> describe above, which whilst admittedly mostly undocumented other than
> in the behaviour of various common tools, are widespread in Linux
> software other than PAM.
> 
That semantics is different among various systems in the wild. As you noted, 
there's no standard on that. Generic implementation shouldn't depend on them. 
Also, see the above again.

> It might make sense for this behaviour to configurable via a pam_unix
> command line option, because otherwise it may be too incompatible to
> make in a 1.0.x release of PAM - I am not familiar with the PAM
> project's compatibility policy. Were it not for compatibility concerns,
> I would suggest that it should be unconditional, as it is a standard
> facet of "traditional unix" security as applied to Linux, which is
> exactly what pam_unix is all about.
> 
That will break many existing installations. Solar Designer in his post 
completely described why. And again, password hash checking is the job of auth 
stack, not the account one. Account stack was designed to check and enforce 
account restrictions, not the password hash, the more that there is no strict 
standard on it.
-- 

    Sincerely Your, Dan.