Debian Bug report logs - #389183
passwd: 'passwd -l/-u' should edit the shadow account expiry field *in addition* to editing the password field as they do know

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: sumbit@bugs.debian.org

Subject: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Wed, 5 Nov 2003 20:00:20 -0500

Package: ssh
Version: 3.4p1-1.woody.3
Severity: Important

If a ~/.ssh/authorized_key file exists and a user's account is locked
with 'passwd -l' the user can still log in despite the locked account.

A system administrator who uses passwd to lock the account may not be
aware of the authorized_key file and thus fail to effectively lock the
account.
 
-- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
--
Excuse #145: Short leg on process table 

Message #10 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: Jeremy Avnet <brainsik@theory.org>

Cc: debian-ssh@lists.debian.org, 219377@bugs.debian.org

Subject: Re: Bug#219377: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 6 Nov 2003 03:10:36 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 05 Nov 2003 at 08:35:25PM -0500, Jeremy Avnet wrote:
> On 5 Nov 2003, at 5:00 PM, Phillip Hofmeister wrote:
> >If a ~/.ssh/authorized_key file exists and a user's account is locked
> >with 'passwd -l' the user can still log in despite the locked account.
> 
> Is this a bug or a feature?
> Is there a better way of going about forcing an account to only accept 
> login with an ssh key?

I guess it may be a feature request, perhaps a configuration option.  It
would make sense that if an account is being disabled that logins would
not be allowed.  I suppose there are some instances where this would not
be the case.

If you think this is a feature/configuration request then it man be
appropriate to mark this bug wishlist and forward it upstream.

- -- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
- --
Excuse #129: Stubborn processes 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/qgHlS3Jybf3L5MQRAjCnAKCECECkolXjnW/Ct2oDIaqeFoDylwCePzP7
4yPI83WRMmurVwuG59zlfuc=
=Ui1u
-----END PGP SIGNATURE-----

Message #15 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Matthew Vernon <matthew@sel.cam.ac.uk>

To: Phillip Hofmeister <plhofmei@zionlth.org>, 219377@bugs.debian.org

Subject: Bug#219377: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 6 Nov 2003 10:09:48 +0000

Phillip Hofmeister writes:
 > Package: ssh
 > Version: 3.4p1-1.woody.3
 > Severity: Important
 > 
 > If a ~/.ssh/authorized_key file exists and a user's account is locked
 > with 'passwd -l' the user can still log in despite the locked account.
 
This is trivially true - all passwd -l does it make the password field
in the {shadow,passwd} file be a value that nothing encrypts to, thus
preventing successful password authentication.

If a user is using publickey authentication, then no password check is
made (that's rather the point) - therefore it will be impossible to
disable access by simply fiddling with the password file.

Accordingly, if a sysadmin wants to be able to disable accounts using
passwd -l, then they'll have to enforce password authentication on all
logins. 

Matthew 

-- 
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org

Message #20 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: Matthew Vernon <matthew@sel.cam.ac.uk>

Cc: 219377@bugs.debian.org

Subject: Re: Bug#219377: SSHd: Ignores Pam Lockout When using SSH PubKey Auth

Date: Thu, 6 Nov 2003 05:28:17 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 06 Nov 2003 at 05:09:48AM -0500, Matthew Vernon wrote:
> This is trivially true - all passwd -l does it make the password field
> in the {shadow,passwd} file be a value that nothing encrypts to, thus
> preventing successful password authentication.
> 
> If a user is using publickey authentication, then no password check is
> made (that's rather the point) - therefore it will be impossible to
> disable access by simply fiddling with the password file.
> 
> Accordingly, if a sysadmin wants to be able to disable accounts using
> passwd -l, then they'll have to enforce password authentication on all
> logins. 

Actually, using passwd -l adds a ! to the front of the password hash
which is easily detected.  In fact, passwd -S can detect this:

smeister L 05/29/2003 5 180 28 30

So I believe this is definitely something that is doable without forcing
passwords for every login.

- -- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.txt | gpg --import
- --
Excuse #187: Fanout dropping voltage too much try cutting some of those little traces 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/qiIsS3Jybf3L5MQRAlG9AJwOIPMRrWTlnw0LxSwzQ3Ncx3JjEgCdGyOR
SEJufigXSn53Y6dXMbHiy6A=
=YpHt
-----END PGP SIGNATURE-----

Message #25 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Darren Tucker <dtucker@zip.com.au>

To: 219377@bugs.debian.org, Phillip Hofmeister <plhofmei@zionlth.org>

Subject: Debian bug #219377: further info

Date: Sun, 09 Nov 2003 17:38:09 +1100

Hi.
	I have some further info regarding the Debian bug you reported ("sshd
ignores PAM lockout when using pubkey auth").

	Recently this was addressed in the upstream source (3.7p1 and up) for the
non-PAM case.  On platforms that have a concept of a locked account, sshd
checks for the specific string that denotes a locked account on that
platform.

	When running with PAM enabled, however, sshd delegates all account checks
to PAM.  Thus the locked account check should be done by PAM (probably in
pam_acct_mgmt).

	Later patchlevels of Solaris do this kind of check in PAM (I think in
pam_acct_mgmt, but I'm not sure of that).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Message #30 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Darren Tucker <dtucker@zip.com.au>, 219377@bugs.debian.org

Cc: Phillip Hofmeister <plhofmei@zionlth.org>, control@bugs.debian.org

Subject: Re: Bug#219377: Debian bug #219377: further info

Date: Sun, 22 Feb 2004 17:45:07 +0000

severity 219377 wishlist
thanks

On Sun, Nov 09, 2003 at 05:38:09PM +1100, Darren Tucker wrote:
> 	I have some further info regarding the Debian bug you reported ("sshd
> ignores PAM lockout when using pubkey auth").
> 
> 	Recently this was addressed in the upstream source (3.7p1 and up) for the
> non-PAM case.  On platforms that have a concept of a locked account, sshd
> checks for the specific string that denotes a locked account on that
> platform.
> 
> 	When running with PAM enabled, however, sshd delegates all account checks
> to PAM.  Thus the locked account check should be done by PAM (probably in
> pam_acct_mgmt).
> 
> 	Later patchlevels of Solaris do this kind of check in PAM (I think in
> pam_acct_mgmt, but I'm not sure of that).

To lock an account, I think you should set the shell to /bin/false or
/dev/null or similar. Having asked around, I know people who
deliberately lock the password to force public-key authentication only;
implementing this feature request would break that facility.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]

Message #37 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Phillip Hofmeister <plhofmei@zionlth.org>

To: Colin Watson <cjwatson@debian.org>

Cc: Darren Tucker <dtucker@zip.com.au>, 219377@bugs.debian.org

Subject: Re: Bug#219377: Debian bug #219377: further info

Date: Sun, 22 Feb 2004 23:59:22 -0500

It wouldn't break that functionality if it were made a config file
option...

On Sun, 22 Feb 2004 at 12:45:07PM -0500, Colin Watson wrote:
> severity 219377 wishlist
> thanks
> 
> On Sun, Nov 09, 2003 at 05:38:09PM +1100, Darren Tucker wrote:
> > 	I have some further info regarding the Debian bug you reported ("sshd
> > ignores PAM lockout when using pubkey auth").
> > 
> > 	Recently this was addressed in the upstream source (3.7p1 and up) for the
> > non-PAM case.  On platforms that have a concept of a locked account, sshd
> > checks for the specific string that denotes a locked account on that
> > platform.
> > 
> > 	When running with PAM enabled, however, sshd delegates all account checks
> > to PAM.  Thus the locked account check should be done by PAM (probably in
> > pam_acct_mgmt).
> > 
> > 	Later patchlevels of Solaris do this kind of check in PAM (I think in
> > pam_acct_mgmt, but I'm not sure of that).
> 
> To lock an account, I think you should set the shell to /bin/false or
> /dev/null or similar. Having asked around, I know people who
> deliberately lock the password to force public-key authentication only;
> implementing this feature request would break that facility.
> 
> Cheers,
> 
> -- 
> Colin Watson                                  [cjwatson@flatline.org.uk]

-- 
Phillip Hofmeister

PGP/GPG Key:
http://www.zionlth.org/~plhofmei/
wget -O - http://www.zionlth.org/~plhofmei/key.asc | gpg --import

Message #42 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Darren Tucker <dtucker@zip.com.au>

To: Phillip Hofmeister <plhofmei@zionlth.org>

Cc: Colin Watson <cjwatson@debian.org>, 219377@bugs.debian.org

Subject: Re: Bug#219377: Debian bug #219377: further info

Date: Mon, 23 Feb 2004 19:23:36 +1100

Phillip Hofmeister wrote:
> It wouldn't break that functionality if it were made a config file
> option...

	IMO, making sshd second-guess PAM when UsePAM=yes would be the Wrong 
Thing, either all the time or as an option.  Speaking as one of the 
upstream OpenSSH developers, it is very unlikely that such a patch would 
be accepted upstream.  Debian is of course welcome to do whatever they 
see fit.

	If you want that behaviour, you should arrange for PAM to do it. 
Putting policy decisions like this in the hands of the system's admin is 
the whole point of PAM.  (You could do it with a module that tests for 
locked accounts in your sshd PAM account stack.  Such a module would be 
trivial to write if one doesn't already exist.)

	Alternatively, you could recompile OpenSSH 3.7.1p2 without PAM, and it 
will behave as you wish.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Message #47 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: 219377@bugs.debian.org

Subject: PAM and shadow and ! and *

Date: Sun, 24 Sep 2006 02:07:10 +0100

[Message part 1 (text/plain, inline)]

Does sshd use PAM's "account" (authorization) mechanism (as opposed to
"auth" (authentication)) when UsePam is enabled? If so then pam_unix
should be able to say "ah, the password starts with a !, therefore the
account is disabled"... according to Steve Langasek[0] this is the case.

[0] http://groups.google.co.uk/group/linux.debian.devel/msg/a54962f20531e4b8

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[signature.asc (application/pgp-signature, inline)]

Message #52 received at 219377@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: 219377@bugs.debian.org

Cc: Debian BTS Control <control@bugs.debian.org>

Subject: re: PAM and shadow and ! and *

Date: Sun, 24 Sep 2006 14:40:06 +0100

[Message part 1 (text/plain, inline)]

clone 219377 -1
reassign -1 libpam-modules
retitle -1 pam_unix: in 'account' mode, deny authorization if user's account is locked
block 219377 by -1
thanks

I did some testing with a test user, ssh and a public key, and it seems
that Steve Langasek is wrong, and pam_unix does not check to see if the
password field is (or is prefixed by) a ! character.

-- 
Sam Morris
http://robots.org.uk/

PGP key id 1024D/5EA01078
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078

[signature.asc (application/pgp-signature, inline)]

Message #65 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 219377@bugs.debian.org, 389183@bugs.debian.org

Cc: Sam Morris <sam@robots.org.uk>, shadow@packages.debian.org

Subject: Re: pam_unix: in 'account' mode, deny authorization if user's account is locked

Date: Sun, 24 Sep 2006 18:16:35 -0700

reassign 389183 libpam-modules,passwd
thanks

> I did some testing with a test user, ssh and a public key, and it seems
> that Steve Langasek is wrong, and pam_unix does not check to see if the
> password field is (or is prefixed by) a ! character.

I don't believe I ever said that pam_unix checks whether the password field
is prefixed by a ! character -- I said that pam_unix checks whether an
account is locked.  Apparently, we're using a couple different definitions
of "locked" here.

"Locking" a user's account by munging the password field is a kludge that
overloads the meaning of this field.  If you want to lock a Unix account
such that pam_unix's authorization checks recognize the account as locked,
there is an account expiry field in the shadow file that I believe is much
more appropriate for this.

But it seems that the passwd command doesn't have an option that will set
this field; it has "passwd -l" and "passwd -u", which manage the "!" in the
password field, and it has "passwd -e", which sets password expiry but *not*
account expiry.

Since, as Colin says, there are people who *expect* that editing the
password field only locks the password, not the account, and this has been
the behavior for, oh... about a decade now, I think it would be better if
the passwd -l/-u option would edit the shadow account expiry field *in
addition* to editing the password field as they do know.  This would
maximize compatibility, while giving passwd -l semantics that more exactly
match the manpage documentation.

So I'm assigning this bug to both libpam-modules and passwd, to get input
from the shadow maintainers.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Message #70 received at 389183-forwarded@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: Tomasz Kłoczko <kloczek@zie.pg.gda.pl>, shadow@pld.org.pl

Cc: 389183-forwarded@bugs.debian.org, vorlon@debian.org

Subject: (forw) [Pkg-shadow-devel] Re: pam_unix: in 'account' mode, deny authorization if user's account is locked

Date: Mon, 25 Sep 2006 06:47:40 +0200

This suggestion comes from the Debian BTS and turns out to be "passwd
-l/-u option should edit the shadow account expiry field *in addition*
to editing the password field".

Tomasz and other contributors to shadow, what's your opinion about it?

----- Forwarded message from Steve Langasek <vorlon@debian.org> -----

Date: Sun, 24 Sep 2006 18:16:35 -0700
From: Steve Langasek <vorlon@debian.org>
To: 219377@bugs.debian.org, 389183@bugs.debian.org
Cc: Sam Morris <sam@robots.org.uk>, shadow@packages.debian.org
Subject: [Pkg-shadow-devel] Re: pam_unix: in 'account' mode,
	deny authorization if user's account is locked
X-CRM114-Status: Good  ( pR: 11.4447 )

reassign 389183 libpam-modules,passwd
thanks

> I did some testing with a test user, ssh and a public key, and it seems
> that Steve Langasek is wrong, and pam_unix does not check to see if the
> password field is (or is prefixed by) a ! character.

I don't believe I ever said that pam_unix checks whether the password field
is prefixed by a ! character -- I said that pam_unix checks whether an
account is locked.  Apparently, we're using a couple different definitions
of "locked" here.

"Locking" a user's account by munging the password field is a kludge that
overloads the meaning of this field.  If you want to lock a Unix account
such that pam_unix's authorization checks recognize the account as locked,
there is an account expiry field in the shadow file that I believe is much
more appropriate for this.

But it seems that the passwd command doesn't have an option that will set
this field; it has "passwd -l" and "passwd -u", which manage the "!" in the
password field, and it has "passwd -e", which sets password expiry but *not*
account expiry.

Since, as Colin says, there are people who *expect* that editing the
password field only locks the password, not the account, and this has been
the behavior for, oh... about a decade now, I think it would be better if
the passwd -l/-u option would edit the shadow account expiry field *in
addition* to editing the password field as they do know.  This would
maximize compatibility, while giving passwd -l semantics that more exactly
match the manpage documentation.

So I'm assigning this bug to both libpam-modules and passwd, to get input
from the shadow maintainers.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

_______________________________________________
Pkg-shadow-devel mailing list
Pkg-shadow-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-shadow-devel

----- End forwarded message -----

Message #75 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: Shadow password utilities project list <shadow@pld.org.pl>, 389183@bugs.debian.org

Subject: Re: (forw) [Pkg-shadow-devel] Re: pam_unix: in 'account' mode, deny authorization if user's account is locked

Date: Tue, 26 Sep 2006 00:13:05 +0200

[Message part 1 (text/plain, inline)]

On Mon, Sep 25, 2006 at 06:47:40AM +0200, bubulle@debian.org wrote:
> This suggestion comes from the Debian BTS and turns out to be "passwd
> -l/-u option should edit the shadow account expiry field *in addition*
> to editing the password field".
> 
> Tomasz and other contributors to shadow, what's your opinion about it?

This sounds good to me.
I can't think of a situation where it would harm.

I'm attaching a patch.
Due to http://bugs.debian.org/308229 I set the accound expiry field to 1
rather than 0. This should be OK (Well, on a system without battery, the
date after a reboot could be 1970-01-01, and the account would not be
expired in that case).

Munging the password field is still necessary (at least on non shadowed
systems).

There is also another utility that can be used to expire an account,
without munging the password field: chage -E.

Kind Regards,
-- 
Nekral

[494_passwd_lock (text/plain, attachment)]

Message #80 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl>

To: Shadow password utilities project list <shadow@pld.org.pl>

Cc: 389183@bugs.debian.org

Subject: Re: (forw) [Pkg-shadow-devel] Re: pam_unix: in 'account' mode, deny authorization if user's account is locked

Date: Tue, 26 Sep 2006 14:14:14 +0200 (CEST)

[Message part 1 (text/plain, inline)]

On Tue, 26 Sep 2006, Nicolas François wrote:
[..]

Sorry for very long time not responding but I was very budy in last few 
weeks and will be in next two (max thtree) days. After this I'll have time
for back to all current work on shadow.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

Message #85 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Justin Pryzby <justinpryzby@users.sourceforge.net>

To: 389183@bugs.debian.org, Nicolas Francois <nicolas.francois@centraliens.net>, Steve Langasek <vorlon@debian.org>

Cc: Colin Watson <cjwatson@debian.org>, Matthew Vernon <matthew@sel.cam.ac.uk>, Phillip Hofmeister <plhofmei@zionlth.org>

Subject: passwd -l to lock account in /etc/shadow as well as /etc/passwd (?)

Date: Mon, 5 Mar 2007 14:57:55 -0500

Regarding Debian bug #389183:
 pam_unix: in 'account' mode, deny authorization if user's account is locked
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389183

The submitter claims that passwd -l should lock the account (as the
manpage claims), rather than lock the password.

Colin knows people that use passwd ! munge to enforce public key
authorization by disabling the password, while leaving the account
enabled (in the shadow file "expires on this many days after 1970"
field).

Steve suggested that passwd -l expire the password in passwd and the
account in shadow; Nicolas implemented this.

Unfortunately I'm not sure how this helps.  Are we assuming that one
doesn't use passwd -l but rather vipw to enforce public key auth?
Otherwise the behavior change will suddenly begin to upset Colin's
people, right?

Justin
(sorry for long cc list)

Message #92 received at 389183-close@bugs.debian.org (full text, mbox, reply):

From: Christian Perrier <bubulle@debian.org>

To: 389183-close@bugs.debian.org

Subject: Bug#389183: fixed in shadow 1:4.0.18.1-10

Date: Fri, 22 Jun 2007 00:47:20 +0000

Source: shadow
Source-Version: 1:4.0.18.1-10

We believe that the bug you reported is fixed in the latest version of
shadow, which is due to be installed in the Debian FTP archive:

login_4.0.18.1-10_i386.deb
  to pool/main/s/shadow/login_4.0.18.1-10_i386.deb
passwd_4.0.18.1-10_i386.deb
  to pool/main/s/shadow/passwd_4.0.18.1-10_i386.deb
shadow_4.0.18.1-10.diff.gz
  to pool/main/s/shadow/shadow_4.0.18.1-10.diff.gz
shadow_4.0.18.1-10.dsc
  to pool/main/s/shadow/shadow_4.0.18.1-10.dsc



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 389183@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier <bubulle@debian.org> (supplier of updated shadow package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sun, 17 Jun 2007 07:38:14 +0200
Source: shadow
Binary: login passwd
Architecture: source i386
Version: 1:4.0.18.1-10
Distribution: unstable
Urgency: low
Maintainer: Shadow package maintainers <pkg-shadow-devel@lists.alioth.debian.org>
Changed-By: Christian Perrier <bubulle@debian.org>
Description: 
 login      - system login tools
 passwd     - change and administer password and group data
Closes: 259494 384164 386818 389183 396690 396726 400683 425689
Changes: 
 shadow (1:4.0.18.1-10) unstable; urgency=low
 .
   * The "Trappe d'Échourgnac" release
   * Upstream bugs fixed in upstream's CVS:
     - 302_su_man_mention_sg: mention sg(1) in su man page. Closes: #396690
     - 303_wording_fixes_in_su_man: minor wording fixes in su(1)
   * Upstream bugs not fixed in upstream's CVS:
     - 410_newgrp_man_mention_sg: mention sg(1) in newgrp man page
     - 201_fix_man_su_fr: fix translation error in french translation for su(1)
     - 202_it_man_uses_gettext: switch italian manpages to gettext. This will
       fix missing paragraphs in translated manpages. Closes: #425689
     - 411_chpasswd_document_no_pam: Document that chgpasswd do not use PAM to
       update the passwords. Thus functionnalities provided by PAM modules are
       not present in chgpasswd (e.g. writting the old password in
       /etc/security/opasswd). Closes: #396726
     - 412_lastlog_-u_numerical_range: allow numerical UID and range of IDs in
       argument to lastog -u. Closes: #259494
     - 413_no-sorry-in-passwd: No longer print 'Sorry' when something
       fails in passwd, su and newgrp. Closes: #384164
     - 414_remove-unwise-advices: Remove not so wise advices about choosing
       passwords. Closes: #386818
     - 494_passwd_lock: set the account expiry field when using
       "passwd -l/-u". Closes: #389183
   * Debian packaging fixes:
     - 506_relaxed_usernames: do not allow spaces in usernames. This was at
       least broken with username starting with a space or tabulation (the user
       can be added but not removed). Closes: #400683
Files: 
 e37e8cdd45798222147e5bf8d328552d 1053 admin required shadow_4.0.18.1-10.dsc
 788d057e2b5e7c13d3bd1995885abad0 214403 admin required shadow_4.0.18.1-10.diff.gz
 afda0301ddf8e94e14089f00c72bdebe 700836 admin required passwd_4.0.18.1-10_i386.deb
 48fa8a3ca1769c30f65d522ee4cd1669 788970 admin required login_4.0.18.1-10_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGelY21OXtrMAUPS0RAkReAJ9WVJiOATekGRu9SNOPibo+/hQ7dACgiPnj
g1uUw2Z8lIEihg5VlngeVMc=
=8CMs
-----END PGP SIGNATURE-----

Message #113 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: control@bugs.debian.org

Cc: 389183@bugs.debian.org

Subject: tagging 389183

Date: Sat, 02 Aug 2008 13:46:32 -0700

# Automatically generated email from bts, devscripts version 2.10.35
# assigned to two packages; it's not decided yet that this applies
tags 389183 - wontfix

Message #122 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Nicolas François <nicolas.francois@centraliens.net>

To: Steve Langasek <vorlon@debian.org>, Sam Morris <sam@robots.org.uk>, 389183@bugs.debian.org

Subject: Re: Bug#389183: passwd: 'passwd -l/-u' should edit the shadow account expiry field *in addition* to editing the password field as they do know

Date: Sun, 3 Aug 2008 05:13:57 +0200

tags 389183 wontfix
thanks

This bug is indeed not fixed since its patch was reverted.

I decided to revert it because it breaks some expectations from users
used to passwd -l only locking the passwd.

I could have a look at 3 different sources:
 * pwdutils (provides passwd on Suse)
   passwd -l is documented as locking the account but only locks the
   user's account (as documented by the usage string)
 * OpenSolaris
   locks the user's password
 * fedora's passwd package
   passwd -l is documented as locking the account but only locks the
   user's account

The reversion was done after 492307, which was triggered by Ubuntu bugs:
  * https://bugs.launchpad.net/bugs/185767
  * https://bugs.launchpad.net/bugs/238755
  * https://bugs.launchpad.net/bugs/251696

These bugs were caused by users expecting passwd -l to only lock the
password / users being recommended to use passwd -l:
https://help.ubuntu.com/community/RootSudo

I currently think that passwd should only touch the password.
(I would also prefer usermod --lock to locks the account)

Together with the reversion of the patch, I documented passwd -l to
actually mention what it really does:
       -l, --lock
           Lock the password of the named account. This option disables a
           password by changing it to a value which matches no possible
           encrypted value (it adds a ´!´ at the beginning of the password.

           Note that this does not disable the account. The user may still be
           able to login using another authentication token (e.g. an SSH key).
           To disable the account, administrators should use usermod
           --expiredate 1 (this set the account´s expire date to Jan 2, 1970).

           Users with a locked password are not allowed to change their
           password.

Best Regards,
-- 
Nekral

Message #133 received at 389183@bugs.debian.org (full text, mbox, reply):

From: Sam Morris <sam@robots.org.uk>

To: Debian Bug Tracking System <389183@bugs.debian.org>

Subject: Re: passwd: 'passwd -l/-u' should edit the shadow account expiry field *in addition* to editing the password field as they do know

Date: Tue, 29 Nov 2022 09:37:42 +0000

Package: shadow,libpam-modules
Followup-For: Bug #389183

A note to software archeologists: this was reverted in June 2007 by
shadow 1:4.1.1-3, with the following remarks in the changelog:

  * debian/patches/494_passwd_lock-no_account_lock: Restore the previous
    behavior of passwd -l (which changed in #389183): only lock the user's
    password, not the user's account. Also explicitly document the
    differences. This restores a behavior common with the previous versions of
    passwd and with other implementations. Closes: #492307

The changelog shipped by the package doesn't go back that far.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Send a report that this bug log contains spam.