bin/71147: sshd(8) will allow to log into a locked account

[Yar Tikhiy]

The following reply was made to PR bin/71147; it has been noted by GNATS.

From: Yar Tikhiy <yar at comp.chem.msu.su>
To: "Simon L. Nielsen" <simon at FreeBSD.org>
Cc: freebsd-gnats-submit at FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Sun, 5 Sep 2004 19:22:07 +0400

 On Sat, Sep 04, 2004 at 09:03:02PM +0200, Simon L. Nielsen wrote:
 > On 2004.09.04 19:52:38 +0400, Yar Tikhiy wrote:
 > > On Sat, Sep 04, 2004 at 05:13:14PM +0200, Simon L. Nielsen wrote:
 > > > On 2004.09.02 16:47:27 +0400, Yar Tikhiy wrote:
 > > > > 
 > > > > Will Kerberos authentication codepath check for ``*LOCKED*'' either?
 > > > 
 > > > No, I actually think Kerberos telnetd will allow login just as long as
 > > > there is a user account and a valid Lerberos account/ticket.
 > > 
 > > That's a manifestation of the problem I had in mind when opening
 > > this PR.  Namely, there is a discrepancy between the existence of
 > > a system-wide policy for locking user accounts on the one hand and
 > > having to implement the said policy in each piece of software
 > > involved on the other hand.  If we decide here that the policy does
 > > exist, it will seem reasonable to implement it where it belongs to,
 > > i.e. in setusercontext().  The function may check for ``*LOCKED*''
 > > if invoked with LOGIN_SETLOGIN set and return an error correspondingly.
 > > With this approach, we could leave alone sshd, telnetd, login, su,
 > > X display managers, as well as any logon-related sw using the function.
 > 
 > While I have no idea if setusercontext() is the right place to check,
 > something like what you propose sounds like a very good idea to me so
 > there is consistent behavior.
 
 Since we develop a research operating system here, I think we are free
 to stick the check up to the function and see how it will work for the
 users :-)
 
 -- 
 Yar