From yar@stylish.chem.msu.su  Mon Aug 30 12:53:53 2004
Return-Path: <yar@stylish.chem.msu.su>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 90D3D16A4CE; Mon, 30 Aug 2004 12:53:53 +0000 (GMT)
Received: from stylish.chem.msu.su (stylish.chem.msu.su [158.250.32.111])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id B274543D39; Mon, 30 Aug 2004 12:53:49 +0000 (GMT)
	(envelope-from yar@stylish.chem.msu.su)
Received: from stylish.chem.msu.su (localhost [127.0.0.1])
	by stylish.chem.msu.su (8.13.1/8.13.1) with ESMTP id i7UCqtop001808;
	Mon, 30 Aug 2004 16:52:55 +0400 (MSD)
	(envelope-from yar@stylish.chem.msu.su)
Received: (from yar@localhost)
	by stylish.chem.msu.su (8.13.1/8.13.1/Submit) id i7UCqs6v001807;
	Mon, 30 Aug 2004 16:52:54 +0400 (MSD)
	(envelope-from yar)
Message-Id: <200408301252.i7UCqs6v001807@stylish.chem.msu.su>
Date: Mon, 30 Aug 2004 16:52:54 +0400 (MSD)
From: Yar Tikhiy <yar@comp.chem.msu.su>
To: FreeBSD-gnats-submit@freebsd.org
Cc: des@freebsd.org
Subject: sshd(8) will allow to log into a locked account
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         71147
>Category:       bin
>Synopsis:       sshd(8) will allow to log into a locked account
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    yar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 30 13:00:41 GMT 2004
>Closed-Date:    Thu Apr 26 07:10:37 GMT 2007
>Last-Modified:  Thu Apr 26 07:10:37 GMT 2007
>Originator:     Yar Tikhiy
>Release:        FreeBSD 6.0-CURRENT i386
>Organization:
Moscow State University
>Environment:
System: FreeBSD stylish.chem.msu.su 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Fri Aug 27 19:34:38 MSD 2004 root@stylish.chem.msu.su:/usr/obj/usr/src/sys/STYLISH i386

>Description:
	In FreeBSD (and other BSDs,) the well-known way to lock out
	a user's account is setting the user's encrypted password to
	an asterisk character, `*', in master.passwd.  Arguably, one
	can also lock out a user by just _prefixing_ the password field
	value with `*'.  Anyway, sshd(8) will ignore either lock
	and allow the user to log in if he authenticates himself by
	means other than the Unix password, e.g., using his public key.

>How-To-Repeat:
	1) set up pub-key authentication for a user;

	2) lock out the user's account by setting the password field
	   of the user's record in master.passwd to just an asterisk.

	3) try to log into the account via SSH using the user's pub-key;

	4) see successful login.

>Fix:
	If we forget about PAM for a while, the bug exists because
	src/crypto/openssh/configure.ac lacks description of account
	locking for FreeBSD.  It may be added to the OpenSSH source
	tree or to the FreeBSD source tree, but in either case it's
	a FreeBSD-specific issue.  The fix is as follows: find the
	FreeBSD-specific section (search for "freebsd") and add an AC
	macro there specifying the lock method.  It may be

	AC_DEFINE(LOCKED_PASSWD_STRING, "*")

	or

	AC_DEFINE(LOCKED_PASSWD_PREFIX, "*")

	depending on which "tradition" we decide to stick to.

	Why does PAM allows locked users in?  That's another issue...
>Release-Note:
>Audit-Trail:

From: Gleb Smirnoff <glebius@freebsd.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: FreeBSD-gnats-submit@freebsd.org, des@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 17:50:14 +0400

 On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 Y> 	In FreeBSD (and other BSDs,) the well-known way to lock out
 Y> 	a user's account is setting the user's encrypted password to
 Y> 	an asterisk character, `*', in master.passwd.  Arguably, one
 Y> 	can also lock out a user by just _prefixing_ the password field
 Y> 	value with `*'.  Anyway, sshd(8) will ignore either lock
 Y> 	and allow the user to log in if he authenticates himself by
 Y> 	means other than the Unix password, e.g., using his public key.
 
 This is not a bug, it's a feature! Any ssh (not only Open) has the
 same behavior on any unix operating system.
 
 I'm utilizing this feature since I use pubkey authentification. 
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Gleb Smirnoff <glebius@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org, des@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 18:00:21 +0400

 On Mon, Aug 30, 2004 at 05:50:14PM +0400, Gleb Smirnoff wrote:
 > On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 > Y> 	In FreeBSD (and other BSDs,) the well-known way to lock out
 > Y> 	a user's account is setting the user's encrypted password to
 > Y> 	an asterisk character, `*', in master.passwd.  Arguably, one
 > Y> 	can also lock out a user by just _prefixing_ the password field
 > Y> 	value with `*'.  Anyway, sshd(8) will ignore either lock
 > Y> 	and allow the user to log in if he authenticates himself by
 > Y> 	means other than the Unix password, e.g., using his public key.
 > 
 > This is not a bug, it's a feature! Any ssh (not only Open) has the
 > same behavior on any unix operating system.
 
 Has it?  The sshd(8) manpage says a different thing!  And I'll be
 damned if the OpenSSH code doesn't check for OS-specific lock strings
 in the password hash field.
 
 > I'm utilizing this feature since I use pubkey authentification. 
 
 I'm afraid it's a dangerous feature to have.  Personally, I like
 the way described on the sshd(8) manpage: you set the password
 field exactly to the dedicated value to lock out a user completely,
 or you set it to a variant to just disable password-based auth for
 him.  In FreeBSD the dedicated value is `*' (or, perhaps, leading
 `*', as I observed in some communities), while any other character in
 front of a password hash or after it will effectively deny any password
 since our hashes are fixed-length, so they can't be matched by
 a string of a different length.
 
 -- 
 Yar

From: Maxim Konovalov <maxim@macomnet.ru>
To: Gleb Smirnoff <glebius@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 18:37:16 +0400 (MSD)

 On Mon, 30 Aug 2004, 14:00-0000, Gleb Smirnoff wrote:
 
 > The following reply was made to PR bin/71147; it has been noted by GNATS.
 >
 > From: Gleb Smirnoff <glebius@freebsd.org>
 > To: Yar Tikhiy <yar@comp.chem.msu.su>
 > Cc: FreeBSD-gnats-submit@freebsd.org, des@freebsd.org
 > Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
 > Date: Mon, 30 Aug 2004 17:50:14 +0400
 >
 >  On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 >  Y> 	In FreeBSD (and other BSDs,) the well-known way to lock out
 >  Y> 	a user's account is setting the user's encrypted password to
 >  Y> 	an asterisk character, `*', in master.passwd.  Arguably, one
 >  Y> 	can also lock out a user by just _prefixing_ the password field
 >  Y> 	value with `*'.  Anyway, sshd(8) will ignore either lock
 >  Y> 	and allow the user to log in if he authenticates himself by
 >  Y> 	means other than the Unix password, e.g., using his public key.
 >
 >  This is not a bug, it's a feature! Any ssh (not only Open) has the
 >  same behavior on any unix operating system.
 
 sshd works as expected (does not allow to login to a system) on
 solaris 8.
 
 -- 
 Maxim Konovalov

From: Ruslan Ermilov <ru@freebsd.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: FreeBSD-gnats-submit@freebsd.org, des@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 17:59:48 +0300

 On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 > 
 > >Description:
 > 	In FreeBSD (and other BSDs,) the well-known way to lock out
 > 	a user's account is setting the user's encrypted password to
 > 	an asterisk character, `*', in master.passwd.  Arguably, one
 > 	can also lock out a user by just _prefixing_ the password field
 > 	value with `*'.  Anyway, sshd(8) will ignore either lock
 > 	and allow the user to log in if he authenticates himself by
 > 	means other than the Unix password, e.g., using his public key.
 > 
 Yes, if sshd(8) is configured accordingly.
 
 > >Fix:
 > 	If we forget about PAM for a while, the bug exists because
 > 	src/crypto/openssh/configure.ac lacks description of account
 > 	locking for FreeBSD.  It may be added to the OpenSSH source
 > 	tree or to the FreeBSD source tree, but in either case it's
 > 	a FreeBSD-specific issue.  The fix is as follows: find the
 > 	FreeBSD-specific section (search for "freebsd") and add an AC
 > 	macro there specifying the lock method.  It may be
 > 
 > 	AC_DEFINE(LOCKED_PASSWD_STRING, "*")
 > 
 > 	or
 > 
 > 	AC_DEFINE(LOCKED_PASSWD_PREFIX, "*")
 > 
 > 	depending on which "tradition" we decide to stick to.
 > 
 > 	Why does PAM allows locked users in?  That's another issue...
 > 
 PAM does not -- it's the pubkey authentification that does.  If you
 disable public key authentification method in sshd_config(5) (which
 is enabled by default) then only PAM will be used, and no user with
 locked password will be able to log in.
 
 What you're probably looking for is to set the PubkeyAuthentication
 and RSAAuthentication parameters to "no" in /etc/ssh/sshd_config.
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Ruslan Ermilov <ru@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org, des@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 19:57:51 +0400

 On Mon, Aug 30, 2004 at 05:59:48PM +0300, Ruslan Ermilov wrote:
 > On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 > > 
 > > >Description:
 > > 	In FreeBSD (and other BSDs,) the well-known way to lock out
 > > 	a user's account is setting the user's encrypted password to
 > > 	an asterisk character, `*', in master.passwd.  Arguably, one
 > > 	can also lock out a user by just _prefixing_ the password field
 > > 	value with `*'.  Anyway, sshd(8) will ignore either lock
 > > 	and allow the user to log in if he authenticates himself by
 > > 	means other than the Unix password, e.g., using his public key.
 > > 
 > Yes, if sshd(8) is configured accordingly.
 > 
 > > >Fix:
 > > 	If we forget about PAM for a while, the bug exists because
 > > 	src/crypto/openssh/configure.ac lacks description of account
 > > 	locking for FreeBSD.  It may be added to the OpenSSH source
 > > 	tree or to the FreeBSD source tree, but in either case it's
 > > 	a FreeBSD-specific issue.  The fix is as follows: find the
 > > 	FreeBSD-specific section (search for "freebsd") and add an AC
 > > 	macro there specifying the lock method.  It may be
 > > 
 > > 	AC_DEFINE(LOCKED_PASSWD_STRING, "*")
 > > 
 > > 	or
 > > 
 > > 	AC_DEFINE(LOCKED_PASSWD_PREFIX, "*")
 > > 
 > > 	depending on which "tradition" we decide to stick to.
 > > 
 > > 	Why does PAM allows locked users in?  That's another issue...
 > > 
 > PAM does not -- it's the pubkey authentification that does.  If you
 > disable public key authentification method in sshd_config(5) (which
 > is enabled by default) then only PAM will be used, and no user with
 > locked password will be able to log in.
 > 
 > What you're probably looking for is to set the PubkeyAuthentication
 > and RSAAuthentication parameters to "no" in /etc/ssh/sshd_config.
 
 Excuse me, I seem to have confused PAM with the login capabilities
 subsystem.  Of course, PAM is just another way of authenticating a
 user.
 
 There is a lot of ways to check user's identity: public key, Unix
 password, TACACS+, RADIUS etc.  However, we are still in the Unix
 reality, where there must exist a 1-to-1 correspondence between
 user's identity and a local account.  And the common sense of this
 Unix reality dictates IMHO that when I'm putting `*' into user's
 password field of master.passwd, I do mean locking the user out of
 the system.  Note that the passwd database originally served both
 purposes, authentication and defining accounts.  Now there are other
 ways of authentication, but account info is still kept in the passwd
 database.
 
 In other words: An authentication subsystem guarantees that the user
 connecting to my system is actually Joe Random User.  However, the
 asterisk is a _well-known_ way to tell, "OK, you've proven to be J.R.User,
 but now I want you to stay off my system until I allow you in."
 
 That's my point here.
 
 -- 
 Yar

From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: Ruslan Ermilov <ru@freebsd.org>, FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 18:11:37 +0200

 Yar Tikhiy <yar@comp.chem.msu.su> writes:
 > There is a lot of ways to check user's identity: public key, Unix
 > password, TACACS+, RADIUS etc.  However, we are still in the Unix
 > reality, where there must exist a 1-to-1 correspondence between
 > user's identity and a local account.  And the common sense of this
 > Unix reality dictates IMHO that when I'm putting `*' into user's
 > password field of master.passwd, I do mean locking the user out of
 > the system.
 
 That's a policy decision, not an inherent feature of the underlying
 mechanism.
 
 > In other words: An authentication subsystem guarantees that the user
 > connecting to my system is actually Joe Random User.  However, the
 > asterisk is a _well-known_ way to tell, "OK, you've proven to be J.R.User,
 > but now I want you to stay off my system until I allow you in."
 
 pw usermod joe -s /usr/sbin/nologin
 
 DES
 --=20
 Dag-Erling Sm=F8rgrav - des@des.no

From: Ceri Davies <ceri@submonkey.net>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: FreeBSD Gnats Submit <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 17:16:02 +0100

 On Mon, Aug 30, 2004 at 02:10:30PM +0000, Yar Tikhiy wrote:
 > The following reply was made to PR bin/71147; it has been noted by GNATS.
 > 
 > From: Yar Tikhiy <yar@comp.chem.msu.su>
 > To: Gleb Smirnoff <glebius@freebsd.org>
 > Cc: FreeBSD-gnats-submit@freebsd.org, des@freebsd.org
 > Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
 > Date: Mon, 30 Aug 2004 18:00:21 +0400
 > 
 >  On Mon, Aug 30, 2004 at 05:50:14PM +0400, Gleb Smirnoff wrote:
 >  > On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 >  > Y> 	In FreeBSD (and other BSDs,) the well-known way to lock out
 >  > Y> 	a user's account is setting the user's encrypted password to
 >  > Y> 	an asterisk character, `*', in master.passwd.  Arguably, one
 >  > Y> 	can also lock out a user by just _prefixing_ the password field
 >  > Y> 	value with `*'.  Anyway, sshd(8) will ignore either lock
 >  > Y> 	and allow the user to log in if he authenticates himself by
 >  > Y> 	means other than the Unix password, e.g., using his public key.
 >  > 
 >  > This is not a bug, it's a feature! Any ssh (not only Open) has the
 >  > same behavior on any unix operating system.
 >  
 >  Has it?  The sshd(8) manpage says a different thing!  And I'll be
 >  damned if the OpenSSH code doesn't check for OS-specific lock strings
 >  in the password hash field.
 >  
 >  > I'm utilizing this feature since I use pubkey authentification. 
 >  
 >  I'm afraid it's a dangerous feature to have.  Personally, I like
 >  the way described on the sshd(8) manpage: you set the password
 >  field exactly to the dedicated value to lock out a user completely,
 >  or you set it to a variant to just disable password-based auth for
 >  him.  In FreeBSD the dedicated value is `*' (or, perhaps, leading
 >  `*', as I observed in some communities), while any other character in
 >  front of a password hash or after it will effectively deny any password
 >  since our hashes are fixed-length, so they can't be matched by
 >  a string of a different length.
 
 This sounds like a reasonable workaround - this way everyone gets a way
 to do what they want.
 
 Ceri
 -- 
 It is not tinfoil, it is my new skin.  I am a robot.

From: Maxim Konovalov <maxim@macomnet.ru>
To: Ceri Davies <ceri@submonkey.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 20:24:48 +0400 (MSD)

 [...]
 > >  sshd works as expected (does not allow to login to a system) on
 > >  solaris 8.
 >
 > Solaris has two strings for locked out accounts:
 >
 > 	*LK* which indicates that an account is locked
 > 	*NP* which indicates that an account has no password and that
 > 	     only other authentication mechanisms should succeed
 >
 > Which one works?
 
 *LK*
 
 -- 
 Maxim Konovalov

From: Ceri Davies <ceri@submonkey.net>
To: Dag-Erling Sm?rgrav <des@des.no>
Cc: FreeBSD Gnats Submit <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Mon, 30 Aug 2004 17:39:08 +0100

 On Mon, Aug 30, 2004 at 04:20:21PM +0000, Dag-Erling Sm?rgrav wrote:
 > The following reply was made to PR bin/71147; it has been noted by GNATS.
 > 
 > From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=)
 > To: Yar Tikhiy <yar@comp.chem.msu.su>
 > Cc: Ruslan Ermilov <ru@freebsd.org>, FreeBSD-gnats-submit@freebsd.org
 > Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
 > Date: Mon, 30 Aug 2004 18:11:37 +0200
 > 
 >  Yar Tikhiy <yar@comp.chem.msu.su> writes:
 >  > There is a lot of ways to check user's identity: public key, Unix
 >  > password, TACACS+, RADIUS etc.  However, we are still in the Unix
 >  > reality, where there must exist a 1-to-1 correspondence between
 >  > user's identity and a local account.  And the common sense of this
 >  > Unix reality dictates IMHO that when I'm putting `*' into user's
 >  > password field of master.passwd, I do mean locking the user out of
 >  > the system.
 >  
 >  That's a policy decision, not an inherent feature of the underlying
 >  mechanism.
 >  
 >  > In other words: An authentication subsystem guarantees that the user
 >  > connecting to my system is actually Joe Random User.  However, the
 >  > asterisk is a _well-known_ way to tell, "OK, you've proven to be J.R.User,
 >  > but now I want you to stay off my system until I allow you in."
 >  
 >  pw usermod joe -s /usr/sbin/nologin
 
 This is arguably what "pw lock joe" should do then.
 It certainly sounds like prepending "*LOCKED*" is either incorrect, or
 that sshd should be checking for *LOCKED*.
 
 Ceri
 -- 
 It is not tinfoil, it is my new skin.  I am a robot.

From: Ruslan Ermilov <ru@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Tue, 31 Aug 2004 15:07:57 +0300

 Yar asked me to follow up here...
 
 As it turns out, this feature is available only in recent
 OpenSSH versions (I haven't investigated which version it
 first appeared in).  I originally looked at the 4.x version
 of the sshd(8) manpage, and it didn't mention any such
 feature.  In HEAD, OpenSSH provides this useful feature;
 here's a relevant excerpt from the sshd(8) manpage in HEAD:
 
 : Regardless of the authentication type, the account is
 : checked to ensure that it is accessible.  An account is
 : not accessible if it is locked, listed in DenyUsers or
 : its group is listed in DenyGroups .  The definition of
 : a locked account is system dependant. Some platforms have
 : their own account database (eg AIX) and some modify the
 : passwd field ( `*LK*' on Solaris, `*' on HP-UX, containing
 : `Nologin' on Tru64 and a leading `!!' on Linux).  If there
 : is a requirement to disable password authentication for
 : the account while allowing still public-key, then the
 : passwd field should be set to something other than these
 : values (eg `NP' or `*NP*' ).
 
 For FreeBSD, I think the locking type should match the one
 used by pw(8):
 
 : USER LOCKING
 :  The pw utility supports a simple password locking mechanism
 :  for users; it works by prepending the string `*LOCKED*'
 :  to the beginning of the password field in master.passwd
 :  to prevent successful authentication.  The lock and unlock
 :  commands take a user name or uid of the account to lock
 :  or unlock, respectively.  The -V, -C, and -q options as
 :  described above are accepted by these commands.
 
 That would be (in the patch form):
 
 %%%
 Index: configure.ac
 ===================================================================
 RCS file: /home/ncvs/src/crypto/openssh/configure.ac,v
 retrieving revision 1.9
 diff -u -r1.9 configure.ac
 --- configure.ac	20 Apr 2004 09:46:39 -0000	1.9
 +++ configure.ac	31 Aug 2004 12:05:17 -0000
 @@ -264,6 +264,7 @@
  	;;
  *-*-freebsd*)
  	check_for_libcrypt_later=1
 +	AC_DEFINE(LOCKED_PASSWD_PREFIX, "*LOCKED*")
  	;;
  *-*-bsdi*)
  	AC_DEFINE(SETEUID_BREAKS_SETUID)
 %%%
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Dag-Erling Sm?rgrav <des@des.no>
Cc: Ruslan Ermilov <ru@freebsd.org>, FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Wed, 1 Sep 2004 07:01:36 +0400

 On Mon, Aug 30, 2004 at 06:11:37PM +0200, Dag-Erling Sm?rgrav wrote:
 > Yar Tikhiy <yar@comp.chem.msu.su> writes:
 > > There is a lot of ways to check user's identity: public key, Unix
 > > password, TACACS+, RADIUS etc.  However, we are still in the Unix
 > > reality, where there must exist a 1-to-1 correspondence between
 > > user's identity and a local account.  And the common sense of this
 > > Unix reality dictates IMHO that when I'm putting `*' into user's
 > > password field of master.passwd, I do mean locking the user out of
 > > the system.
 > 
 > That's a policy decision, not an inherent feature of the underlying
 > mechanism.
 
 Yes, but this policy decision has become the best current practice,
 and diverging from it isn't significantly better than renaming `ls'
 to `dir' so that users migrating from MS Windows are happy.
  
 > > In other words: An authentication subsystem guarantees that the user
 > > connecting to my system is actually Joe Random User.  However, the
 > > asterisk is a _well-known_ way to tell, "OK, you've proven to be J.R.User,
 > > but now I want you to stay off my system until I allow you in."
 > 
 > pw usermod joe -s /usr/sbin/nologin
 
 As it has already been noted in the audit trail, pw(8) implements
 account locking of its own, which in fact sticks to the asterisk
 locking practice.  The native locking of pw(8) is also better than
 assigning nologin(8) as the user's shell because the former can be
 undone, which makes performing lock/unlock cycles really easy.
 Assigning nologin(8) is more to completely disabling an account
 than to locking it.
 
 However, I feel that the full blown prefix `*LOCKED*' should be
 left for pw(8) purposes while just a leading asterisk may be
 considered by sshd(8) as a sure sign of an account being locked.
 E.g., the macro PASSWD_LOCK_PREFIX("*") should be used IMHO.
 
 -- 
 Yar

From: Ceri Davies <ceri@submonkey.net>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: FreeBSD Gnats Submit <freebsd-gnats-submit@FreeBSD.org>
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Wed, 1 Sep 2004 11:32:06 +0100

 On Wed, Sep 01, 2004 at 03:10:22AM +0000, Yar Tikhiy wrote:
 
 >  However, I feel that the full blown prefix `*LOCKED*' should be
 >  left for pw(8) purposes while just a leading asterisk may be
 >  considered by sshd(8) as a sure sign of an account being locked.
 >  E.g., the macro PASSWD_LOCK_PREFIX("*") should be used IMHO.
 
 I don't agree, Yar.  I think that "pw lock" should be the canonical way
 to lock an account, that *LOCKED* should therefore be the string that ssh
 checks for on FreeBSD (pw has been doing this for nearly five years, so
 I believe that this is the defacto standard now), and that any other string
 should be interpreted as "fail password authentication" only.
 
 Whatever we choose, the string should be passed back to the OpenSSH team
 so that they can check for it.
 
 And this should all be documented as such, obviously ;-)
 
 Ceri
 -- 
 It is not tinfoil, it is my new skin.  I am a robot.

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Ceri Davies <ceri@submonkey.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Wed, 1 Sep 2004 14:03:59 +0300

 On Wed, Sep 01, 2004 at 10:40:23AM +0000, Ceri Davies wrote:
 >  I don't agree, Yar.  I think that "pw lock" should be the canonical way
 >  to lock an account, that *LOCKED* should therefore be the string that ssh
 >  checks for on FreeBSD (pw has been doing this for nearly five years, so
 >  I believe that this is the defacto standard now), and that any other string
 >  should be interpreted as "fail password authentication" only.
 >  
 >  Whatever we choose, the string should be passed back to the OpenSSH team
 >  so that they can check for it.
 >  
 >  And this should all be documented as such, obviously ;-)
 >  
 Matching against the `*' prefix will also match the *LOCKED* prefix,
 so I don't personally see a big problem here.  But *LOCKED* looks
 nicer to me, and for anyone editing in vipw(8) anyway.
 
 
 Cheers,
 -- 
 Ruslan Ermilov
 ru@FreeBSD.org
 FreeBSD committer

From: "Simon L. Nielsen" <simon@FreeBSD.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Wed, 1 Sep 2004 17:06:21 +0200

 --IiVenqGWf+H9Y6IX
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2004.09.01 03:10:22 +0000, Yar Tikhiy wrote:
 > The following reply was made to PR bin/71147; it has been noted by GNATS.
 >=20
 >  However, I feel that the full blown prefix `*LOCKED*' should be
 >  left for pw(8) purposes while just a leading asterisk may be
 >  considered by sshd(8) as a sure sign of an account being locked.
 >  E.g., the macro PASSWD_LOCK_PREFIX("*") should be used IMHO.
 
 If you prevent accounts with a "*" from logging in with a ssh key you
 will break POLA.  I know that I have several systems where the
 password in master.passwd is set to "*" and I then log in via ssh
 keys.
 
 Also a "*" in the password file does not prevent a user logging in
 when authenticating via Kerberos.
 
 --=20
 Simon L. Nielsen
 FreeBSD Documentation Team
 
 --IiVenqGWf+H9Y6IX
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.5 (FreeBSD)
 
 iD8DBQFBNeVth9pcDSc1mlERAry9AJ9e/YuimUR2/MdQZTl32tw5f8i1UgCgrAOi
 UvI51SjxveTY26yrQ3bEwYg=
 =dJ0F
 -----END PGP SIGNATURE-----
 
 --IiVenqGWf+H9Y6IX--

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

 On Wed, Sep 01, 2004 at 05:06:21PM +0200, Simon L. Nielsen wrote:
 > On 2004.09.01 03:10:22 +0000, Yar Tikhiy wrote:
 > > The following reply was made to PR bin/71147; it has been noted by GNATS.
 > > 
 > >  However, I feel that the full blown prefix `*LOCKED*' should be
 > >  left for pw(8) purposes while just a leading asterisk may be
 > >  considered by sshd(8) as a sure sign of an account being locked.
 > >  E.g., the macro PASSWD_LOCK_PREFIX("*") should be used IMHO.
 > 
 > If you prevent accounts with a "*" from logging in with a ssh key you
 > will break POLA.  I know that I have several systems where the
 > password in master.passwd is set to "*" and I then log in via ssh
 > keys.
 > 
 > Also a "*" in the password file does not prevent a user logging in
 > when authenticating via Kerberos.
 
 Will Kerberos authentication codepath check for ``*LOCKED*'' either?
 
 -- 
 Yar

From: "Simon L. Nielsen" <simon@FreeBSD.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Sat, 4 Sep 2004 17:13:14 +0200

 --vEao7xgI/oilGqZ+
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2004.09.02 16:47:27 +0400, Yar Tikhiy wrote:
 > On Wed, Sep 01, 2004 at 05:06:21PM +0200, Simon L. Nielsen wrote:
 > > On 2004.09.01 03:10:22 +0000, Yar Tikhiy wrote:
 > > > The following reply was made to PR bin/71147; it has been noted by GN=
 ATS.
 > > >=20
 > > >  However, I feel that the full blown prefix `*LOCKED*' should be
 > > >  left for pw(8) purposes while just a leading asterisk may be
 > > >  considered by sshd(8) as a sure sign of an account being locked.
 > > >  E.g., the macro PASSWD_LOCK_PREFIX("*") should be used IMHO.
 > >=20
 > > If you prevent accounts with a "*" from logging in with a ssh key you
 > > will break POLA.  I know that I have several systems where the
 > > password in master.passwd is set to "*" and I then log in via ssh
 > > keys.
 > >=20
 > > Also a "*" in the password file does not prevent a user logging in
 > > when authenticating via Kerberos.
 >=20
 > 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.
 
 --=20
 Simon L. Nielsen
 FreeBSD Documentation Team
 
 --vEao7xgI/oilGqZ+
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.5 (FreeBSD)
 
 iD8DBQFBOduKh9pcDSc1mlERAnhvAJ4jmrlBlc9vcB62zwZHTIEeDTlFgwCggyWT
 x6hpYoehlliHSI20PwA+6eU=
 =AAWw
 -----END PGP SIGNATURE-----
 
 --vEao7xgI/oilGqZ+--

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

 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:
 > > On Wed, Sep 01, 2004 at 05:06:21PM +0200, Simon L. Nielsen wrote:
 > > > 
 > > > Also a "*" in the password file does not prevent a user logging in
 > > > when authenticating via Kerberos.
 > > 
 > > 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.
 
 -- 
 Yar

From: "Simon L. Nielsen" <simon@FreeBSD.org>
To: Yar Tikhiy <yar@comp.chem.msu.su>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Sat, 4 Sep 2004 21:03:02 +0200

 --k1lZvvs/B4yU6o8G
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 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:
 > > >=20
 > > > Will Kerberos authentication codepath check for ``*LOCKED*'' either?
 > >=20
 > > No, I actually think Kerberos telnetd will allow login just as long as
 > > there is a user account and a valid Lerberos account/ticket.
 >=20
 > 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.
 
 --=20
 Simon L. Nielsen
 FreeBSD Documentation Team
 
 --k1lZvvs/B4yU6o8G
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.5 (FreeBSD)
 
 iD8DBQFBOhFlh9pcDSc1mlERAphpAJ9YRkxK02PiWdnoUlQshzyJJb6BFwCgpzw3
 m+3e4D1JbXjACAAtjOa3u3A=
 =Eu36
 -----END PGP SIGNATURE-----
 
 --k1lZvvs/B4yU6o8G--

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: "Simon L. Nielsen" <simon@FreeBSD.org>
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

From: Maxim Konovalov <maxim@macomnet.ru>
To: Ceri Davies <ceri@submonkey.net>
Cc: bug-followup@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Sun, 3 Jul 2005 11:14:13 +0400 (MSD)

 [...]
 > >  >  On Mon, Aug 30, 2004 at 04:52:54PM +0400, Yar Tikhiy wrote:
 > >  >  Y> 	In FreeBSD (and other BSDs,) the well-known way to lock out
 > >  >  Y> 	a user's account is setting the user's encrypted password to
 > >  >  Y> 	an asterisk character, `*', in master.passwd.  Arguably, one
 > >  >  Y> 	can also lock out a user by just _prefixing_ the password field
 > >  >  Y> 	value with `*'.  Anyway, sshd(8) will ignore either lock
 > >  >  Y> 	and allow the user to log in if he authenticates himself by
 > >  >  Y> 	means other than the Unix password, e.g., using his public key.
 > >  >
 > >  >  This is not a bug, it's a feature! Any ssh (not only Open) has the
 > >  >  same behavior on any unix operating system.
 > >
 > >  sshd works as expected (does not allow to login to a system) on
 > >  solaris 8.
 >
 > Solaris has two strings for locked out accounts:
 >
 > 	*LK* which indicates that an account is locked
 > 	*NP* which indicates that an account has no password and that
 > 	     only other authentication mechanisms should succeed
 >
 > Which one works?
 
 Both work as described.
 
 -- 
 Maxim Konovalov
State-Changed-From-To: open->feedback 
State-Changed-By: remko 
State-Changed-When: Wed Feb 28 12:12:49 UTC 2007 
State-Changed-Why:  
Is this resolved in the meantime? 


Responsible-Changed-From-To: freebsd-bugs->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Wed Feb 28 12:12:49 UTC 2007 
Responsible-Changed-Why:  
grab the pr 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71147 

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: Remko Lodder <remko@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Sun, 4 Mar 2007 01:44:34 +0300

 On Wed, Feb 28, 2007 at 12:13:12PM +0000, Remko Lodder wrote:
 > Synopsis: sshd(8) will allow to log into a locked account
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: remko
 > State-Changed-When: Wed Feb 28 12:12:49 UTC 2007
 > State-Changed-Why: 
 > Is this resolved in the meantime?
 
 The problem is partially solved.  OpenSSH had grown awareness of
 our passwd locking scheme by 4.3p1, according to the CVS history
 of its configure.ac.  With PAM turned off in sshd_config, it correctly
 refuses logins by locked users.  OTOH, in the default mode, with
 PAM on, it still lets them in.
 
 I mean users conventionally locked with "pw lock" and having the
 *LOCKED* prefix before their password hash.
 
 Tested in 6.2-RELEASE and a fresh CURRENT.
 
 The pam_unix module seems to be the next thing to be fixed.  It
 does account management already, but it should consult locked status
 in addition to password expiry date and auth_*ok() functions.
 By the way, password expiry date works OK with sshd and PAM: I
 cannot login in my system via ssh if I set the password expiry date
 for my user to back in the past.
 
 -- 
 Yar

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: des@freebsd.org
Cc: bug-followup@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Sun, 4 Mar 2007 02:51:32 +0300

 On Sun, Mar 04, 2007 at 01:44:33AM +0300, Yar Tikhiy wrote:
 > On Wed, Feb 28, 2007 at 12:13:12PM +0000, Remko Lodder wrote:
 > > Synopsis: sshd(8) will allow to log into a locked account
 > > 
 > > State-Changed-From-To: open->feedback
 > > State-Changed-By: remko
 > > State-Changed-When: Wed Feb 28 12:12:49 UTC 2007
 > > State-Changed-Why: 
 > > Is this resolved in the meantime?
 > 
 > The problem is partially solved.  OpenSSH had grown awareness of
 > our passwd locking scheme by 4.3p1, according to the CVS history
 > of its configure.ac.  With PAM turned off in sshd_config, it correctly
 > refuses logins by locked users.  OTOH, in the default mode, with
 > PAM on, it still lets them in.
 > 
 > I mean users conventionally locked with "pw lock" and having the
 > *LOCKED* prefix before their password hash.
 > 
 > Tested in 6.2-RELEASE and a fresh CURRENT.
 > 
 > The pam_unix module seems to be the next thing to be fixed.  It
 > does account management already, but it should consult locked status
 > in addition to password expiry date and auth_*ok() functions.
 > By the way, password expiry date works OK with sshd and PAM: I
 > cannot login in my system via ssh if I set the password expiry date
 > for my user to back in the past.
 
 Here's a working patch for pam_unix.  Dag-Erling, what is your
 opinion about it?  Thanks!
 
 -- 
 Yar
 
 Index: pam_unix.c
 ===================================================================
 RCS file: /home/ncvs/src/lib/libpam/modules/pam_unix/pam_unix.c,v
 retrieving revision 1.51
 diff -u -p -r1.51 pam_unix.c
 --- pam_unix.c	5 Jul 2005 18:42:18 -0000	1.51
 +++ pam_unix.c	3 Mar 2007 23:37:49 -0000
 @@ -70,6 +70,9 @@ __FBSDID("$FreeBSD: src/lib/libpam/modul
  #define DEFAULT_WARN		(2L * 7L * 86400L)  /* Two weeks */
  #define	SALTSIZE		32
  
 +#define	LOCKED_PREFIX		"*LOCKED*"
 +#define	LOCKED_PREFIX_LEN	(sizeof(LOCKED_PREFIX) - 1)
 +
  static void makesalt(char []);
  
  static char password_hash[] =		PASSWORD_HASH;
 @@ -176,6 +179,9 @@ pam_sm_acct_mgmt(pam_handle_t *pamh, int
  	    (flags & PAM_DISALLOW_NULL_AUTHTOK) != 0)
  		return (PAM_NEW_AUTHTOK_REQD);
  
 +	if (strncmp(pwd->pw_passwd, LOCKED_PREFIX, LOCKED_PREFIX_LEN) == 0)
 +		return (PAM_AUTH_ERR);
 +
  	lc = login_getpwclass(pwd);
  	if (lc == NULL) {
  		PAM_LOG("Unable to get login class for user %s", user);
State-Changed-From-To: feedback->analyzed 
State-Changed-By: yar 
State-Changed-When: Tue Mar 20 07:13:29 UTC 2007 
State-Changed-Why:  
The problem still is there, but now it's understood. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71147 

From: Yar Tikhiy <yar@comp.chem.msu.su>
To: des@freebsd.org
Cc: bug-followup@freebsd.org
Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
Date: Tue, 20 Mar 2007 10:12:57 +0300

 Dag-Erling, did you receive this mail?  Resending it just in case.
 Sorry for the nagging, but you're listed as the maintainer of libpam.
 Thanks!
 
 ----- Forwarded message from Yar Tikhiy <yar@comp.chem.msu.su> -----
 
 From: Yar Tikhiy <yar@comp.chem.msu.su>
 To: des@freebsd.org
 Cc: bug-followup@freebsd.org
 Subject: Re: bin/71147: sshd(8) will allow to log into a locked account
 Date: Sun, 4 Mar 2007 02:51:32 +0300
 Message-ID: <20070303235132.GE40430@comp.chem.msu.su>
 
 On Sun, Mar 04, 2007 at 01:44:33AM +0300, Yar Tikhiy wrote:
 > On Wed, Feb 28, 2007 at 12:13:12PM +0000, Remko Lodder wrote:
 > > Synopsis: sshd(8) will allow to log into a locked account
 > > 
 > > State-Changed-From-To: open->feedback
 > > State-Changed-By: remko
 > > State-Changed-When: Wed Feb 28 12:12:49 UTC 2007
 > > State-Changed-Why: 
 > > Is this resolved in the meantime?
 > 
 > The problem is partially solved.  OpenSSH had grown awareness of
 > our passwd locking scheme by 4.3p1, according to the CVS history
 > of its configure.ac.  With PAM turned off in sshd_config, it correctly
 > refuses logins by locked users.  OTOH, in the default mode, with
 > PAM on, it still lets them in.
 > 
 > I mean users conventionally locked with "pw lock" and having the
 > *LOCKED* prefix before their password hash.
 > 
 > Tested in 6.2-RELEASE and a fresh CURRENT.
 > 
 > The pam_unix module seems to be the next thing to be fixed.  It
 > does account management already, but it should consult locked status
 > in addition to password expiry date and auth_*ok() functions.
 > By the way, password expiry date works OK with sshd and PAM: I
 > cannot login in my system via ssh if I set the password expiry date
 > for my user to back in the past.
 
 Here's a working patch for pam_unix.  Dag-Erling, what is your
 opinion about it?  Thanks!
 
 -- 
 Yar
 
 Index: pam_unix.c
 ===================================================================
 RCS file: /home/ncvs/src/lib/libpam/modules/pam_unix/pam_unix.c,v
 retrieving revision 1.51
 diff -u -p -r1.51 pam_unix.c
 --- pam_unix.c	5 Jul 2005 18:42:18 -0000	1.51
 +++ pam_unix.c	3 Mar 2007 23:37:49 -0000
 @@ -70,6 +70,9 @@ __FBSDID("$FreeBSD: src/lib/libpam/modul
  #define DEFAULT_WARN		(2L * 7L * 86400L)  /* Two weeks */
  #define	SALTSIZE		32
  
 +#define	LOCKED_PREFIX		"*LOCKED*"
 +#define	LOCKED_PREFIX_LEN	(sizeof(LOCKED_PREFIX) - 1)
 +
  static void makesalt(char []);
  
  static char password_hash[] =		PASSWORD_HASH;
 @@ -176,6 +179,9 @@ pam_sm_acct_mgmt(pam_handle_t *pamh, int
  	    (flags & PAM_DISALLOW_NULL_AUTHTOK) != 0)
  		return (PAM_NEW_AUTHTOK_REQD);
  
 +	if (strncmp(pwd->pw_passwd, LOCKED_PREFIX, LOCKED_PREFIX_LEN) == 0)
 +		return (PAM_AUTH_ERR);
 +
  	lc = login_getpwclass(pwd);
  	if (lc == NULL) {
  		PAM_LOG("Unable to get login class for user %s", user);
 
 ----- End forwarded message -----
 
 -- 
 Yar
Responsible-Changed-From-To: remko->yar 
Responsible-Changed-By: yar 
Responsible-Changed-When: Tue Mar 20 08:28:08 UTC 2007 
Responsible-Changed-Why:  
I've got the patch to commit. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71147 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/71147: commit references a PR
Date: Tue, 27 Mar 2007 09:59:24 +0000 (UTC)

 yar         2007-03-27 09:59:15 UTC
 
   FreeBSD src repository
 
   Modified files:
     lib/libpam/modules/pam_unix pam_unix.8 pam_unix.c 
   Log:
   In account management, verify whether the account has been locked
   with `pw lock', so that it's impossible to log into a locked account
   using an alternative authentication mechanism, such as an ssh key.
   This change affects only accounts locked with pw(8), i.e., having a
   `*LOCKED*' prefix in their password hash field, so people still can
   use a different pattern to disable password authentication only.
   
   Mention all account management criteria in the manpage.
   
   Approved by:    maintainer (timeout)
   PR:             bin/71147
   MFC after:      1 month
   
   Revision  Changes    Path
   1.13      +16 -3     src/lib/libpam/modules/pam_unix/pam_unix.8
   1.52      +6 -0      src/lib/libpam/modules/pam_unix/pam_unix.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: analyzed->patched 
State-Changed-By: yar 
State-Changed-When: Tue Mar 27 10:01:13 UTC 2007 
State-Changed-Why:  
pam_unix(8) fixed in HEAD to pay attention to locked status of the account. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71147 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/71147: commit references a PR
Date: Thu, 26 Apr 2007 06:39:12 +0000 (UTC)

 yar         2007-04-26 06:39:01 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     lib/libpam/modules/pam_unix pam_unix.8 pam_unix.c 
   Log:
   MFC:
           pam_unix.c      1.52
           pam_unix.8      1.13
   
     In account management, verify whether the account has been locked
     with `pw lock', so that it's impossible to log into a locked account
     using an alternative authentication mechanism, such as an ssh key.
     This change affects only accounts locked with pw(8), i.e., having a
     `*LOCKED*' prefix in their password hash field, so people still can
     use a different pattern to disable password authentication only.
   
     Mention all account management criteria in the manpage.
   
   PR:             bin/71147
   
   Revision  Changes    Path
   1.11.2.2  +16 -3     src/lib/libpam/modules/pam_unix/pam_unix.8
   1.51.2.1  +6 -0      src/lib/libpam/modules/pam_unix/pam_unix.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: yar 
State-Changed-When: Thu Apr 26 06:41:50 UTC 2007 
State-Changed-Why:  
MFC done. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=71147 
>Unformatted:
