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

Package: adduser
Version: 3.102

adduser has 2 options:

|adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
|[--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
|[--disabled-password] [--disabled-login] USER
 ^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^^^
|  Add a normal user

Internally, disabled-login seems to disable more than disabled-password:
            "disabled-password" => sub { $ask_passwd = 0 },
	    "disabled-login" => sub { $disabled_login = 1; $ask_passwd = 0
},

And the manpage is consistent with this interpretation:

|      --disabled-login
|      Do not run passwd to set the password.  The user won''t be able
|      to use her account until the password is set.

|      --disabled-password
|      Like --disabled-login, but logins are still possible (for exam-
|      ple using SSH RSA keys) but not using password authentication.


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??

disabled-login makes the shadow file have a "*":  

|   } else /* if ($ask_passwd) */ {
|                   if(!$disabled_login) {
|       		    my $usermod = &which(''usermod'');
|       		    &systemcall($usermod, ''-p'',
''*'', $new_name);
|       	    }
|   }

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.

This one time, at band camp, Justin Pryzby said:
> adduser has 2 options:
> |[--disabled-password] [--disabled-login] USER
>  ^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^^^
> 
> Internally, disabled-login seems to disable more than disabled-password:
>             "disabled-password" => sub { $ask_passwd = 0 },
> 	    "disabled-login" => sub { $disabled_login = 1;
$ask_passwd = 0 },
> 
> And the manpage is consistent with this interpretation:
Correct so far.
> 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.
> 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?
-- 
 -----------------------------------------------------------------
|   ,''''`.                                            Stephen
Gran |
|  : :'' :                                        sgran@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/20070227/e38023c2/attachment.pgp

On Tue, Feb 27, 2007 at 11:16:49PM +0000, Stephen Gran
wrote:
> This one time, at band camp, Justin Pryzby said:
> > adduser has 2 options:
> > |[--disabled-password] [--disabled-login] USER
> >  ^^^^^^^^^^^^^^^^^^^   ^^^^^^^^^^^^^^^^
> > 
> > Internally, disabled-login seems to disable more than
disabled-password:
> >             "disabled-password" => sub { $ask_passwd = 0
},
> > 	    "disabled-login" => sub { $disabled_login = 1;
$ask_passwd = 0 },
> > 
> > And the manpage is consistent with this interpretation:
> 
> Correct so far.
> 
> > 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?

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@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

Your message dated Wed, 4 Jun 2008 00:58:02 +0100
with message-id <20080603235802.GA30654 at www.lobefin.net>
and subject line well, no reply in a year seems like not a bug
has caused the Debian Bug report #412742,
regarding adduser: neither disabled{password,login} disables the account
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner at bugs.debian.org
immediately.)


-- 
412742: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412742
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems
-------------- next part --------------
An embedded message was scrubbed...
From: Justin Pryzby <justinpryzby at users.sourceforge.net>
Subject: adduser: neither disabled{password,login} disables the account
Date: Tue, 27 Feb 2007 14:56:47 -0500
Size: 2977
Url:
http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20080604/380c137d/attachment.eml
-------------- next part --------------
An embedded message was scrubbed...
From: Stephen Gran <sgran at debian.org>
Subject: well, no reply in a year seems like not a bug
Date: Wed, 4 Jun 2008 00:58:02 +0100
Size: 3105
Url:
http://lists.alioth.debian.org/pipermail/adduser-devel/attachments/20080604/380c137d/attachment-0001.eml