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 _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"