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

[Damien Miller]

Darren Tucker wrote:
>>I think password disabling via expired passwords would be a better way.
>>OpenBSD by default supports this behavior so it is consistant and I know
>>shadow and PAM systems support it.
> 
> You mean account disabling via expired account?  If you use an expired
> password to lock an account you won't be able to use password expiry
> for, well, making people change their passwords.

I think Ben means the shadow sp_expire field, which I understand means 
"account expiry" rather than "password expiry". This would be IMO a 
nicer way of doing things.

> Some platforms (eg HP-UX in non-trusted mode) have a concept of locked
> accounts but don't have password aging or account expiry.
> 
> It boils down to "does passwd -l lock the account or the password?" From
> the man pages I've checked the ratio is 2 (account) to 1 (password).
> 
> So you can default to allowing locked entries (permissive by default) or
> not allowing them (secure by default[0]).

That argument would carry more weight for me, but for the fact that 
(AFAIK) SSH has never honored locked passwords as locking pubkey access.

This could lead to a whole lot of people who have used locked accounts + 
pubkey access suddenly finding that they can no longer access their 
systems post-upgrade.

The way out of that would be to add a preference to determine the 
behaviour - but I don't want to add more portable-specific options (In 
fact I want to get rid of the one that is there).

> Martin MOKREJ© has kindly supplied some info about Tru64's
> -lauthenticate functions so we could drop the ugliest Tru64 cases and
> have another section at the end of allowed_user() like
> WITH_AIXAUTHENTICATE.  Then it would look something like

Shouldn't this be done for Tru64 using SIA anyway?

-d