[Adduser-devel] Bug#625758: 'adduser --disabled-login' does not behave as documented.
Sam Morris
sam at robots.org.uk
Sat Jul 27 10:43:20 UTC 2013
On Sat, 2013-07-27 at 08:44 +0100, Stephen Gran wrote:
> This one time, at band camp, Sam Morris said:
> > On Fri, 2013-07-26 at 19:39 +0100, Stephen Gran wrote:
> > > This one time, at band camp, Sam Morris said:
> > > > Therefore I don't see the use of having both options, unless some other
> > > > software cares about the difference between the two values,
> > >
> > > They do mean something different:
> > >
> > > From the wikipedia page:
> > >
> > > "NP" or "!" or null - No password, the account has no password.
> > > "LK" or "*" - the account is Locked, user will be unable to log-in
> > >
> > > There is a semantic difference between the two. ! in the field says
> > > that authentication with a password should never succeed. * says that
> > > login should never succeed, even if alternate forms of authentication
> > > (such as ssh keys) are in use. The above chunk of code is correct if it
> > > is in a password checking routine - both should return false for
> > > authentication.
> >
> > See <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=219377>. It is
> > possible to SSH in to a machine as an account with only * in its
> > password field. In addition, shadow(5) doesn't draw any distinction
> > between the two values:
> >
> > If the password field contains some string that is not a valid
> > result of crypt(3), for instance ! or *, the user will not be
> > able to use a unix password to log in (but the user may log in
> > the system by other means).
> >
> > pam_unix's accounting code doesn't use the password field at all--only
> > the additional fields in the shadow file.
> >
> > My gut feeling is that if there ever was a distinction between the two
> > values, it is lost to history. Perhaps * used to be used before the
> > advent of shadow files to indicate that the entire account was locked
> > rather than just the password. I don't know, I wasn't around in those
> > days. :)
>
> So, I think that maybe I'm confused - I am under the impression that
> you started by saying that there is no useful difference between the
> two states 'locked' and 'disabled'. I responded by saying there was.
> In defense of your statement, you've pointed me to a bug report that
> says that pam now looks elsewhere to distinguish between the two states,
> and that it was a bug in shadow not to set that other flag, and that
> that bug is now fixed.
Sorry, I meant to also draw your attention to the clone bug,
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389183#122>. The fix
was reverted because, as it turns out, people were used to the old
behaviour (that 'passwd -l' would lock the password, and not the entire
account).
(I think Nicolas made a couple of typos when composing that message, and
sometimes said 'account' where he meant 'password', so read the bullet
points carefully.)
As an aside, I did some more searching and found that OpenSSH, if you
disable PAM, will take ! to mean disable the entire account & deny
access without attempting authentication. This can be seen at
<http://sources.debian.net/src/openssh/1:6.2p2-6/auth.c#L134>.
In fact, <http://sources.debian.net/src/openssh/1:6.2p2-6/configure.ac>
reveals how OpenSSH interprets the password field on various UNIXes when
PAM is disabled:
Host OS String Mode Note
-------------------------------------------------------------
HP-UX * exact
IRIX *LK* exact
GNU/kFreeBSD ! prefix
GNU/kOpenSolaris ! prefix
Linux ! prefix
FreeBSD *LOCKED* prefix
Solaris *LK* exact
UnixWare/OpenUNIX *LK* exact
Tru64 Unix NoLogin substring When OSF SIA disabled
This information may be of some historical interest. It gives that
Wikipedia page something to cite, at least. :)
--
Sam Morris <https://robots.org.uk/>
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20130727/5675146b/attachment-0001.sig>
More information about the Adduser-devel
mailing list