Bug#625758: 'adduser --disabled-login' does not behave as documented

[Timo Lindfors]

Jan 18, 2023 11:35:43 Marc Haber :
> Yes, that's the UI's error, it just gets what it asks for: A user that
> cannot login.

That's what I expected too but I was actually able to login. The only problem 
was that the gnome-terminal wasn't usable.

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Marc Haber]

On Tue, Jan 17, 2023 at 05:22:19PM +0200, Timo Lindfors wrote:
> I just noticed that if I create a user from Gnome/Settings/Users they will
> have their shell set to /usr/sbin/nologin. The user can login but cannot
> start a terminal. This occurs in a clean sid VM but does not occur in a
> clean Debian 11 VM.
> 
> It seems the UI calls accounts-daemon over dbus and that then runs
> 
> adduser --quiet --disabled-login --gecos username username
> 
> in both cases.
> 
> Is this a separate bug that should be reported against some package?

Yes, that's the UI's error, it just gets what it asks for: A user that
cannot login.

> Oh and btw, the man page in 3.130 seems to have some syntax issue since
> groff markup is shown to the user:
> 
> $ man adduser | grep fP
>   duse's scope.  --disabled-login will additional set the shell
> to  /usr/sbin/nologin/fP.   Valid

That was fixed in git last week, thanks for spotting this.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Timo Lindfors]

Hi,

I just noticed that if I create a user from Gnome/Settings/Users they will 
have their shell set to /usr/sbin/nologin. The user can login but cannot 
start a terminal. This occurs in a clean sid VM but does not occur in a 
clean Debian 11 VM.


It seems the UI calls accounts-daemon over dbus and that then runs

adduser --quiet --disabled-login --gecos username username

in both cases.

Is this a separate bug that should be reported against some package?

Oh and btw, the man page in 3.130 seems to have some syntax issue since 
groff markup is shown to the user:


$ man adduser | grep fP
  duse's scope.  --disabled-login will additional set the 
shell to  /usr/sbin/nologin/fP.   Valid




-Timo

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Marc Haber]

Hi Colin,

On Tue, Jan 03, 2023 at 06:17:36PM +, Colin Watson wrote:
> On Tue, Jan 03, 2023 at 03:04:22PM +0100, Marc Haber wrote:
> > Since this is a matter that you can only do wrong, if you want that
> > changed, please carry this to the TC to get advice.
> 
> I think you may have misread my tone a bit? 

Maybe I missed my tone. I didn't mean to escalate. That was just my
helpless expression of frustration for not having a "team of elders" that
one can ask for guidance BEFORE having a conflict. Having the TC just as
last method of collision avoidance is quite frustrating for me.

> You likely have a
> better overview of the situation around this than I do.

I'd love to have a better overview than I have currently.

> > Thank you very much. Do you think this is worth mentioning in
> > NEWS.Debian?
> 
> If I were you, I'd be inclined to do so if only to reduce time spent on
> support issues in future, but obviously it's up to you.  (Actually, my
> own inclination would probably be to put it in the manual page so that
> it's right there for anyone looking up what --disabled-password means.)

The manual page has been adapted and reworked in 3.130 and I hope that
it is reasonably clear on tht point. I think that the manual page should
explain how things are and explanation about how things got to the
current point should better go into "back-end" documentation.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Colin Watson]

On Tue, Jan 03, 2023 at 03:04:22PM +0100, Marc Haber wrote:
> On Mon, Jan 02, 2023 at 11:04:22PM +, Colin Watson wrote:
> > On Sat, Mar 19, 2022 at 11:44:05AM +0100, Marc Haber wrote:
> > > After discussion in policy and on debian-devel, this is what adduser is
> > > going to do:
> > > 
> > > - document (README.adduser-for-packages, adduser(8)) that
> > >   --disabled-login and --disabled-password are only defined for
> > >   non-system accounts. --system accounts get an invalid password and
> > >   /usr/sbin/nologin unless explicitly requested otherwise regardless of
> > >   the --disabled options. Many packages have adduser --system
> > >   --disabled-(login|password) in their maintainer scripts so we cannot
> > >   change this behavior.
> > > - document (adduser(8)) that --disabled-login will just not set a
> > >   password and leave the password in the state that useradd created.
> > > - change and document (adduser(8)) that --disabled-password will behave
> > >   like --disabled-login and additionally set the shell to
> > >   /usr/sbin/nologin.
> > 
> > FYI, this broke openssh's autopkgtests.  I've pushed
> > https://salsa.debian.org/ssh-team/openssh/-/commit/af3ead2202 to fix
> > that.
> 
> Thanks for fixing that. We literally discussed that over a time of
> weeks, in public, and had to guess a lot about how PAM and ssh handle
> the different state of accounts, and it's sad that this opportunity was
> not picked up by the ssh team, leaving the decision to us as adduser
> team.

I'm afraid I didn't notice the discussion - in practice the SSH team is
pretty much just me, I'd only just returned from some business travel,
March tends to be a pretty busy time of year for me, and I don't think
anyone CCed me or otherwise alerted me that my input was needed
(apologies if that did actually happen and I missed it).  Though I must
admit that I'm a little confused even after reading up on it:
https://lists.debian.org/debian-devel/2022/03/msg00304.html seems to be
a summing-up of the thread, in which you wrote '--disabled-password will
result in a "*" in /etc/shadow, effectively making it impossible to use
any password based authentication', but that seems to be the opposite of
what was implemented (it used to be "*", but is now "!").  So even if I
had noticed the discussion at the time, I might very well have got to
the end of it and concluded that there wasn't going to be a problem.

It's also of course possible that I wouldn't have noticed the issue
until autopkgtests started to fail, since I don't normally pay a lot of
attention to the non-UsePAM case.

> Since this is a matter that you can only do wrong, if you want that
> changed, please carry this to the TC to get advice.

I think you may have misread my tone a bit?  I'm not particularly cross
or anything like that and I'm not necessarily agitating for this to be
changed, just neutrally informing you of a particular regression that
you might otherwise not have been aware of and might wish to take into
account if it lines up with other feedback you get.  You likely have a
better overview of the situation around this than I do.

> > I don't think this affects normal use of OpenSSH in Debian.  The
> > relevant code only runs when UsePAM is disabled, and it so happens that
> > the way we enable UsePAM by default in Debian is via the default
> > /etc/ssh/sshd_config, but the regression tests use their own sshd_config
> > which we don't patch.  (It may be worth looking into running the
> > regression tests with something closer to Debian's default sshd_config
> > at some point; I hadn't noticed this discrepancy until today.)
> 
> It would actually be good if testing would resemble the actual
> environment that Debian installed. Isn't that somewaht the idea of
> testing?

Oh, I quite agree, I just wanted to get the immediate regression fixed
first.  I've pushed
https://salsa.debian.org/ssh-team/openssh/-/commit/51c2542824 to fix
this.

> > but at any rate,
> > I thought I'd mention this particular observed breakage in case you
> > weren't aware of it.
> 
> Thank you very much. Do you think this is worth mentioning in
> NEWS.Debian?

If I were you, I'd be inclined to do so if only to reduce time spent on
support issues in future, but obviously it's up to you.  (Actually, my
own inclination would probably be to put it in the manual page so that
it's right there for anyone looking up what --disabled-password means.)

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Marc Haber]

Hi Colin,

On Mon, Jan 02, 2023 at 11:04:22PM +, Colin Watson wrote:
> On Sat, Mar 19, 2022 at 11:44:05AM +0100, Marc Haber wrote:
> > After discussion in policy and on debian-devel, this is what adduser is
> > going to do:
> > 
> > - document (README.adduser-for-packages, adduser(8)) that
> >   --disabled-login and --disabled-password are only defined for
> >   non-system accounts. --system accounts get an invalid password and
> >   /usr/sbin/nologin unless explicitly requested otherwise regardless of
> >   the --disabled options. Many packages have adduser --system
> >   --disabled-(login|password) in their maintainer scripts so we cannot
> >   change this behavior.
> > - document (adduser(8)) that --disabled-login will just not set a
> >   password and leave the password in the state that useradd created.
> > - change and document (adduser(8)) that --disabled-password will behave
> >   like --disabled-login and additionally set the shell to
> >   /usr/sbin/nologin.
> 
> FYI, this broke openssh's autopkgtests.  I've pushed
> https://salsa.debian.org/ssh-team/openssh/-/commit/af3ead2202 to fix
> that.

Thanks for fixing that. We literally discussed that over a time of
weeks, in public, and had to guess a lot about how PAM and ssh handle
the different state of accounts, and it's sad that this opportunity was
not picked up by the ssh team, leaving the decision to us as adduser
team.

Since this is a matter that you can only do wrong, if you want that
changed, please carry this to the TC to get advice.

> I don't think this affects normal use of OpenSSH in Debian.  The
> relevant code only runs when UsePAM is disabled, and it so happens that
> the way we enable UsePAM by default in Debian is via the default
> /etc/ssh/sshd_config, but the regression tests use their own sshd_config
> which we don't patch.  (It may be worth looking into running the
> regression tests with something closer to Debian's default sshd_config
> at some point; I hadn't noticed this discrepancy until today.)

It would actually be good if testing would resemble the actual
environment that Debian installed. Isn't that somewaht the idea of
testing?

> However,
> it could affect systems where the admin has disabled UsePAM.

Yes, but due to lack of personpower the adduser team cannot cater for
non-default configuration. If a local admin choses to change a setting,
they must be prepared to adapt other pieces of software. The
--disabled-{login|password} was a horrible mess for two decades that
even the adduser maintainers didn't understand.

> I'm not sure I really follow the logic of why the behaviour of
> --disabled-password was changed in this particular way;

It was changed because there were common cases where the result was not
what the --disabled-foo option suggested. We decided not to document
this away but to clean up the mess.

> but at any rate,
> I thought I'd mention this particular observed breakage in case you
> weren't aware of it.

Thank you very much. Do you think this is worth mentioning in
NEWS.Debian?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Colin Watson]

On Sat, Mar 19, 2022 at 11:44:05AM +0100, Marc Haber wrote:
> After discussion in policy and on debian-devel, this is what adduser is
> going to do:
> 
> - document (README.adduser-for-packages, adduser(8)) that
>   --disabled-login and --disabled-password are only defined for
>   non-system accounts. --system accounts get an invalid password and
>   /usr/sbin/nologin unless explicitly requested otherwise regardless of
>   the --disabled options. Many packages have adduser --system
>   --disabled-(login|password) in their maintainer scripts so we cannot
>   change this behavior.
> - document (adduser(8)) that --disabled-login will just not set a
>   password and leave the password in the state that useradd created.
> - change and document (adduser(8)) that --disabled-password will behave
>   like --disabled-login and additionally set the shell to
>   /usr/sbin/nologin.

FYI, this broke openssh's autopkgtests.  I've pushed
https://salsa.debian.org/ssh-team/openssh/-/commit/af3ead2202 to fix
that.

I don't think this affects normal use of OpenSSH in Debian.  The
relevant code only runs when UsePAM is disabled, and it so happens that
the way we enable UsePAM by default in Debian is via the default
/etc/ssh/sshd_config, but the regression tests use their own sshd_config
which we don't patch.  (It may be worth looking into running the
regression tests with something closer to Debian's default sshd_config
at some point; I hadn't noticed this discrepancy until today.)  However,
it could affect systems where the admin has disabled UsePAM.

I'm not sure I really follow the logic of why the behaviour of
--disabled-password was changed in this particular way; but at any rate,
I thought I'd mention this particular observed breakage in case you
weren't aware of it.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Vincent Lefevre]

On 2022-03-19 11:44:05 +0100, Marc Haber wrote:
> - change and document (adduser(8)) that --disabled-password will behave
>   like --disabled-login and additionally set the shell to
>   /usr/sbin/nologin.
> - --disabled-login and an explicitly set --shell is an error and will be
>   flagged as such.

Hmm... Don't you mean "--disabled-login will behave like
--disabled-password and additionally set the shell to
/usr/sbin/nologin"?

So, since --disabled-login sets the shell to /usr/sbin/nologin,
it must not be used in combination with --shell.

BTW, the issue about the behavior occurred in this context:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021613#45

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Marc Haber]

Control: severity -1 important

On Mon, Mar 07, 2022 at 10:12:01PM +0100, Marc Haber wrote:
> I would suggest making both options do the same, just not setting a
> password for the newly created account, document this, and emit in the
> --disabled-login case a warning that logins might still be possible for
> the account. A NEWS.Debian entry is probably in order.
> 
> In the future, we might have a new option, for example
> --no-set-password, and deprecate both old versions of the options.
> 
> afaics, the code path selected by adduser --system does not honor either
> option anyway and just does not set a password. If this is true, this
> should be documented as well. I a not sure whether we should issue a
> warning if adduser --system --disabled-(password|login) is called.

After discussion in policy and on debian-devel, this is what adduser is
going to do:

- document (README.adduser-for-packages, adduser(8)) that
  --disabled-login and --disabled-password are only defined for
  non-system accounts. --system accounts get an invalid password and
  /usr/sbin/nologin unless explicitly requested otherwise regardless of
  the --disabled options. Many packages have adduser --system
  --disabled-(login|password) in their maintainer scripts so we cannot
  change this behavior.
- document (adduser(8)) that --disabled-login will just not set a
  password and leave the password in the state that useradd created.
- change and document (adduser(8)) that --disabled-password will behave
  like --disabled-login and additionally set the shell to
  /usr/sbin/nologin.
- --disabled-login and an explicitly set --shell is an error and will be
  flagged as such.

Greetings
Marc

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Marc Haber]

Control: tags -1 - patch
thanks

Thanks for your work. I am removing the tag "patch" since I do not think
that this problem can be fixed as easily.

Greetings
Marc

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Marc Haber]

Control: tags -1 confirmed
thanks

On Thu, May 05, 2011 at 06:56:37PM +0100, Matthew Woodcraft wrote:
> The adduser manpage in squeeze contains the following:
> 
>--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.

This is used in 73 packages in Debian

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

150 Packages in Debian use this.

We therefore must not break things for packages.

Discussion of historical UNIX behavior does not help us too much.

I would suggest making both options do the same, just not setting a
password for the newly created account, document this, and emit in the
--disabled-login case a warning that logins might still be possible for
the account. A NEWS.Debian entry is probably in order.

In the future, we might have a new option, for example
--no-set-password, and deprecate both old versions of the options.

afaics, the code path selected by adduser --system does not honor either
option anyway and just does not set a password. If this is true, this
should be documented as well. I a not sure whether we should issue a
warning if adduser --system --disabled-(password|login) is called.

Greetings
Marc

Bug#625758: [Adduser-devel] Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Matti Kurkela]

As far as I understand, different implementations had different ways to specify 
the semantics of “disabling the account”. 
So the developers of the passed command went to look for details that would be 
un-ambiguous in all implementations, and this seems to be what they found:

- neither an asterisk nor an exclamation mark in the first character of the 
password hash file alone can be unambiguously interpreted as “disabling the 
account”, because there are conflicting implementations

- however, setting the account expiration date to a non-null value that is in 
the past was found to be a totally unambiguous way to disable an account  
without losing any account details that might be under user’s (limited) 
control, like the user’s shell setting.

- setting the account’s shell to a non-usable value should not be the only way 
to mark the account as “no logins of any type allowed”, since there are plenty 
of valid use cases for accounts with a valid shell but logins disabled.

So the resulting password/account management options relevant to this 
discussion after all was said and done are now:

- an exclamation mark in the first (or only) character of the password hash 
field 
  = a (possibly-temporary) administrative lock on password authentication for 
his user. *Can be unlocked* without changing the existing password, even if the 
existing password is null.

- an asterisk as the first (or only) character of the password hash field
  = a (possibly-permanent) lock on password authentication. Undoing this with 
standard commands requires setting a new password, or an explicit decision to 
set a null password.

- a non-null “account expiration date” value that is not 0 and is in the past = 
account is disabled. This can (and probably should) be used together with one 
of the previous options when creating an application account that should never 
have an ability to login, but is usable with sudo or a similar mechanism.

As a result, the —disabled-login option of the adduser command won’t do what it 
claims to do, if authentication mechanisms other than password authentication 
are in use.

Example: if the sysadmin uses “adduser --disabled-login” to create an 
application user account, and an attacker manages to fool the application into 
writing a valid ~/.ssh/authorized_keys file, it turns out that the 
supposedly-disabled account now allows SSH key authenticated login for the 
attacker. This is unexpected.

The fix: “adduser --disabled-login" needs to perform an explicit “usermod 
--expiredate 1” or equivalent in addition to what it does now. After the 
changes made to the passwd command in 2008, “passwd -l” will no longer do that 
for you.

Bug#625758: [Adduser-devel] Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Stephen Gran]

This one time, at band camp, Sam Morris said:
 On Sat, 2013-07-27 at 08:44 +0100, Stephen Gran wrote:
  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).

`passwd -l` should only lock the password, not the account.  That is
correct.  But this, again, only underlines that there is a difference
between locking the password and locking the account, right?

Look, maybe I'm being dense, but I think we're going around in circles a
bit here.  I think there is a semantic difference between these two
states.  I think it makes sense for adduser to expose that semantic
difference for the initial state of a new user.

I think that you are arguing that there is no difference between the
states, but you keep doing so by pointing at things discussing how the
two states aren't the same.  The whole discussion of passwd or shadow
fields is a red herring - adduser just uses the tools from the shadow
suite, so once they decide with PAM what combination of fields make
sense, adduser will do the right thing.

If you think that there is no difference between a password that can't
be matched and an account that cannot login, or you think that adduser
shouldn't expose this difference, please enlighten me.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Stephen Gran]

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.

It seems to me that the resolution here is, there is a semantic
difference between these two states.  How that is expressed in the passwd
file doesn't actually matter to adduser - adduser just uses passwd and
the other tools to manipulate the files.  If there were bugs in their
handling of the files that are now fixed, then all is well, right?

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Sam Morris]

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


signature.asc
Description: This is a digitally signed message part

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Sam Morris]

tag 625758 + patch
thanks

With --disabled-password, the password field is set to '!'; with
--disabled-login, it is set to '*'. pam_unix checks for both in
verify_pw_hash:

} else if (!p || *hash == '*' || *hash == '!') {
retval = PAM_AUTH_ERR;

Therefore I don't see the use of having both options, unless some other
software cares about the difference between the two values,

On the assumption that there is no such other software, here is an patch
to note that --disabled-login doesn't do anything that
--disabled-password can't.

I've also changed a few stray '-' characters to '\-'.

-- 
Sam Morris https://robots.org.uk/
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078
--- doc/adduser.8.orig	2013-07-26 10:55:33.570533942 +0100
+++ doc/adduser.8	2013-07-26 11:17:12.175202430 +0100
@@ -10,9 +10,9 @@
 .SH NAME
 adduser, addgroup \- add a user or group to the system
 .SH SYNOPSIS
-.BR adduser  [options] [\-\-home DIR] [\-\-shell SHELL] [\-\-no-create-home] [\-\-uid ID] [\-\-firstuid ID] [\-\-lastuid ID] [\-\-ingroup GROUP | \-\-gid ID] [\-\-disabled-password] [\-\-disabled-login] [\-\-gecos GECOS] [\-\-add_extra_groups] user
+.BR adduser  [options] [\-\-home DIR] [\-\-shell SHELL] [\-\-no-create-home] [\-\-uid ID] [\-\-firstuid ID] [\-\-lastuid ID] [\-\-ingroup GROUP | \-\-gid ID] [\-\-disabled\-password] [\-\-disabled\-login] [\-\-gecos GECOS] [\-\-add_extra_groups] user
 .PP
-.BR adduser  \-\-system [options] [\-\-home DIR] [\-\-shell SHELL] [\-\-no-create-home] [\-\-uid ID] [\-\-group | \-\-ingroup GROUP | \-\-gid ID] [\-\-disabled-password] [\-\-disabled-login] [\-\-gecos GECOS] user
+.BR adduser  \-\-system [options] [\-\-home DIR] [\-\-shell SHELL] [\-\-no-create-home] [\-\-uid ID] [\-\-group | \-\-ingroup GROUP | \-\-gid ID] [\-\-disabled\-password] [\-\-disabled\-login] [\-\-gecos GECOS] user
 .PP
 .BR addgroup  [options] [\-\-gid ID] group
 .PP
@@ -92,12 +92,9 @@
 a password.  The gecos may also be set with the
 .B \-\-gecos
 option.  With the
-.B \-\-disabled-login
-option, the account will be created but will be disabled until a
-password is set. The
-.B \-\-disabled-password
-option will not set a password, but login is still possible (for example
-with SSH RSA keys).
+.B \-\-disabled\-password
+option, the account will be created without a password being set; login
+is still possible through other means (for example, with SSH RSA keys).
 
 If the file
 .B /usr/local/sbin/adduser.local
@@ -146,7 +143,7 @@
 .I /bin/false
 (unless overridden with the
 .B \-\-shell
-option), and have logins disabled.  Skeletal configuration files
+option), and have a disabled password.  Skeletal configuration files
 are not copied.
 .SS Add a user group
 If 
@@ -182,12 +179,14 @@
 Use FILE instead of
 .IR /etc/adduser.conf .
 .TP
-.B \-\-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.
+.B \-\-disabled\-login
+Obsolete option with the same effect as \fB\-\-disabled\-password\fR. To disable an
+account, so that login is not possible by any means, set the expiry date after
+.B adduser
+has been run, for example with \fBchage -E 0\fR.
 .TP
-.B \-\-disabled-password
-Like \-\-disabled-login, but logins are still possible (for example using 
+.B \-\-disabled\-password
+Do not run passwd to set the password. Logins are still possible (for example using 
 SSH RSA keys) but not using password authentication.
 .TP
 .B \-\-force\-badname


signature.asc
Description: This is a digitally signed message part

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Stephen Gran]

This one time, at band camp, Sam Morris said:
 tag 625758 + patch
 thanks
 
 With --disabled-password, the password field is set to '!'; with
 --disabled-login, it is set to '*'. pam_unix checks for both in
 verify_pw_hash:
 
   } else if (!p || *hash == '*' || *hash == '!') {
   retval = PAM_AUTH_ERR;
 
 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.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Sam Morris]

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. :)

Regards,

-- 
Sam Morris https://robots.org.uk/
3412 EA18 1277 354B 991B  C869 B219 7FDB 5EA0 1078


signature.asc
Description: This is a digitally signed message part

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Matthew Woodcraft]

Package: adduser
Version: 3.112+nmu2
Severity: normal

The adduser manpage in squeeze contains the following:

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

Similar text has been there for many years, but it hasn't really been
true in Debian since whenever 'UsePAM yes' became the default in
sshd_config: an account created using --disabled-login can still be used
to log in using public-key authentication without a password being set.

I think either the adduser manpage should be changed to not imply that
disabled-login will prevent SSH public-key logins, or else adduser
--disabled-login should be changed to do the equivalent of 'chage -E 1'.


Versions of packages adduser depends on:
ii  debconf [de 1.5.36.1 Debian configuration management sy
ii  passwd  1:4.1.4.2+svn3283-2+squeeze1 change and administer password and
ii  perl-base   5.10.1-17minimal Perl system



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org