From owner-freebsd-bugs@FreeBSD.ORG Sun Sep 5 15:30:26 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC40A16A4CE for ; Sun, 5 Sep 2004 15:30:26 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE69743D49 for ; Sun, 5 Sep 2004 15:30:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i85FUQtF024172 for ; Sun, 5 Sep 2004 15:30:26 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i85FUQSf024171; Sun, 5 Sep 2004 15:30:26 GMT (envelope-from gnats) Date: Sun, 5 Sep 2004 15:30:26 GMT Message-Id: <200409051530.i85FUQSf024171@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Yar Tikhiy Subject: Re: bin/71147: sshd(8) will allow to log into a locked account X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Yar Tikhiy List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 15:30:26 -0000 The following reply was made to PR bin/71147; it has been noted by GNATS. From: Yar Tikhiy To: "Simon L. Nielsen" Cc: freebsd-gnats-submit@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