Test for locked account in auth.c (bug #442).

[Lee Eakin]

> From: Kevin Steves <stevesk at pobox.com>
> On Sun, Jan 12, 2003 at 09:59:52PM +1100, Darren Tucker wrote:
> >  	/* check for locked account */
> > -	if (strcmp(passwd, "*LK*") == 0 || passwd[0] == '!') {
> > +	if (passwd && (strcmp(passwd, "*LK*") == 0 ||	/* Solaris,IRIX */
> > +	    strcmp(passwd, "*") == 0 ||			/* HP-UX,Tru64 */
> > +	    strstr(passwd, "Nologin") ||		/* Tru64 */
> > +#ifdef __osf
> > +	    /* Tru64 but we also want to allow "passwordless" accounts */
> > +	    (passwd[0] == '*' && strcmp(passwd, "*NP*") != 0) ||
> > +#endif
> > +	    passwd[0] == '!')) {			/* Redhat */
> >  		log("User %.100s not allowed because account is locked",
> >  		    pw->pw_name);
> >  		return 0;
> 
> i just wonder if we really want to attempt all these checks.  if you
> lock a user's password but leave the authorized_keys file permitting
> access is the account locked?  there's a split in opinion on that i
> think.
> 
> also, it may be simpler to check for strlen(passwd) < 13, as it may be
> safe to always consider that an invalid password.  maybe.

If we simplify to the point of 'strlen(passwd) < 13' then we would need a
sshd_config option to revert to current behavior (allowing shell of
/bin/false or similar to disable).  I have many key-only accounts in
combination with command= and other key restrictions for security reasons.
It allows me to set up special purpose accounts only accessible thru ssh.

Of course, now that I think about it, defining a password of '*' * 13 or
similar might be a workaround, but I don't know if that might cause strange
behavior in other programs?

-- 
    Lee Eakin - leakin at ti.com - Internet/Naming Services, Texas Instruments
 
LAWS OF COMPUTER PROGRAMMING:
III. If a program is useful, it will have to be changed.