Your message dated Mon, 25 Sep 2006 06:47:40 +0200
with message-id <[email protected]>
has caused the Debian Bug report #389183,
regarding pam_unix: in 'account' mode, deny authorization if user's account is
to be marked as having been forwarded to the upstream software
author(s) Tomasz KÅoczko <[email protected]>, [email protected]
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
(forw) [Pkg-shadow-devel] Re: pam_unix: in 'account' mode, deny authorization if user's account is locked
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 <[email protected]> -----
Date: Sun, 24 Sep 2006 18:16:35 -0700
From: Steve Langasek <[email protected]>
To: [email protected], [email protected]
Cc: Sam Morris <[email protected]>, [email protected]
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
> 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*
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.
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[email protected] http://www.debian.org/
Pkg-shadow-devel mailing list
----- End forwarded message -----
--- End Message ---