Debian Bug report logs - #412742
adduser: neither disabled{password,login} disables the account

Toggle useless messages

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

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

To: submit@bugs.debian.org

Subject: adduser: neither disabled{password,login} disables the account

Date: Tue, 27 Feb 2007 14:56:47 -0500

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.

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

From: Stephen Gran <sgran@debian.org>

To: Justin Pryzby <justinpryzby@users.sourceforge.net>, 412742@bugs.debian.org

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

Date: Tue, 27 Feb 2007 23:16:49 +0000

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

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

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

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

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

To: Stephen Gran <sgran@debian.org>

Cc: 412742@bugs.debian.org

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

Date: Wed, 28 Feb 2007 03:39:32 -0500

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?

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

From: Stephen Gran <sgran@debian.org>

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

Cc: 412742@bugs.debian.org

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

Date: Wed, 28 Feb 2007 11:58:28 +0000

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

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

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

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

From: Stephen Gran <sgran@debian.org>

To: 412742-done@bugs.debian.org

Subject: well, no reply in a year seems like not a bug

Date: Wed, 4 Jun 2008 00:58:02 +0100

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

I haven't heard back what the actual bug was supposed to be, and it's
been a year now.  Closing.
-- 
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

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

Send a report that this bug log contains spam.