Bug#412742: [Adduser-devel] Bug#412742: adduser: neither disabled{password, login} disables the account

[Stephen Gran]

This one time, at band camp, Justin Pryzby said:
> On Tue, Feb 27, 2007 at 11:16:49PM +0000, Stephen Gran wrote:
> > This one time, at band camp, Justin Pryzby said:
> > 
> > > So I expect disabled-password users to be able to login with RSA keys, and
> > > disabled-login users to be completely disabled?  Both of them accept RSA auth
> > > over SSH.  Is there some RSA auth that can happen locally??
> > 
> > All RSA auth happens 'locally', in the sense that the public key being
> > offered has to be somewhere local for the key exchange to succeed.  But
> > this is a fairly obvious answer, so I'm not sure that's what you were
> > really asking.
>
> I was asking if there was some auth mechanism I'm not aware of that
> doesn't use a password that is affected by --disabled-login, which makes
> that option useful..
>
> > > Is some broken login program supposed to be checking for * as a special case?
> > > Are the 1-character flags [x!*] supposed to act differently?
> > > 
> > > Similar bugs include 389183.
> > 
> > And as you'll note, they all run into the same limitation you're
> > finding.  It's a fundamental flaw in the overloading of the meaning of
> > the field.  According to shadow(5):
> > 
> > "If the password field contains some string that is  not  valid result
> > of crypt(3), for instance ! or *, the user will not be able to use a
> > unix password to log in, subject to pam(7)."
> > 
> > I am not sure how this is a bug in adduser, though.  All that adduser
> > can do is handle values available to us through standard tools like
> > usermod and passwd.  It explicitly does not rewrite your pam stack or
> > your sshd config.  But I'm assuming you know that as well, so how are
> > you hoping to see this resolved?
> 
> What is it that --disabled-login does that --disabled-password doesn't?

:~$ sudo adduser --disabled-password test1
:~$ sudo adduser --disabled-login test2
:~$ sudo grep test /etc/shadow:
test1:*:13572:0:99999:7:::
test2:!:13572:0:99999:7:::

Those two entries have slightly different semantics.  * has been
historically taken to mean that the user cannot login, since they can't
authenticate (nothing crypts to *), while ! has been taken to mean the
account is locked.  Whether or not you have pam and/or sshd configured
to take notice of the difference is another matter.  x is a placeholder
for /etc/passwd, meaning the password can be found in /etc/shadow.

But, to repeat, what is the bug?  I feel as though we're going through a
"what does this do?" course, but not getting at the actual bug.  Is the
problem that you would like what these fields do better documented?  Is
it that you don't see these as useful?  Is there a logic error in the
program?
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran at debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20070228/f12ebf0e/attachment.pgp