cvs commit: src/lib/libpam/modules/pam_unix pam_unix.8 pam_unix.c

[Yar Tikhiy]

On Thu, Apr 26, 2007 at 12:46:38PM +0100, Ceri Davies wrote:
> On Thu, Apr 26, 2007 at 01:54:59PM +0300, Alexandr Kovalenko wrote:
> > Hello, Yar Tikhiy!
> > 
> > On Thu, Apr 26, 2007 at 06:39:01AM +0000, you wrote:
> > 
> > > yar         2007-04-26 06:39:01 UTC
> > > 
> > >   FreeBSD src repository
> > > 
> > >   Modified files:        (Branch: RELENG_6)
> > >     lib/libpam/modules/pam_unix pam_unix.8 pam_unix.c 
> > >   Log:
> > >   MFC:
> > >           pam_unix.c      1.52
> > >           pam_unix.8      1.13
> > >   
> > >     In account management, verify whether the account has been locked
> > >     with `pw lock', so that it's impossible to log into a locked account
> > >     using an alternative authentication mechanism, such as an ssh key.
> > >     This change affects only accounts locked with pw(8), i.e., having a
> > >     `*LOCKED*' prefix in their password hash field, so people still can
> > >     use a different pattern to disable password authentication only.
> > 
> > Using the very same logic you should also add checking for '*', and for
> > any other string, which cannot be in password hash of different
> > algorithms. By the way, what if some crypto algorithm, which will be
> > used for password hashing can produce hash, which contains substring
> > '*LOCKED*' ?
> 
> We really need to grow the same mechanism for this as Solaris has.
> The way that this works is:
> 
>   o If the password hash begins *NP* then the user has no password
>      and password authentication will always fail.
> 
>   o If the password hash begins *LK* then the account is considered
>      locked and all authentication fails.  Also, cron and at will
>      not run jobs for that user.
> 
>   o Anything else, the account is considered enabled (although of
>      course, password checking can still fail if the hash is not
>      valid).
> 
> I couldn't care less what the strings actually are, but we should
> probably use *LOCKED* for the locked case, although I can see that we
> may wish to use something else to provide a somewhat backward compatible
> route - those who have been using the string *LOCKED* as stated in the
> pw manual would get the same behaviour that they do now.
> 
> I am willing to work on this, but not without general agreement on the
> above.

I believe that general consensus in PR bin/71147 was that in FreeBSD
a *LOCKED* prefix means the account is totally locked out while a
single asterisk in the password field means password authentication
is disabled.  And, it isn't unfounded.  That practice has already
been supported by adduser(8) for quite a while.  Now OpenSSH, too,
looks for *LOCKED* as the FreeBSD-specific indication of an account
being locked out if PAM isn't used.  So I see my change to pam_unix(8)
just as a step in the direction we've already been moving in.  To
match Solaris, we just need to document our practice well.

-- 
Yar