bin/71147: sshd(8) will allow to log into a locked account
yar at comp.chem.msu.su
Sun Sep 5 08:30:26 PDT 2004
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
More information about the freebsd-bugs