Debian Bug report logs - #625758
'adduser --disabled-login' does not behave as documented.

Toggle useless messages

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

From: Matthew Woodcraft <matthew@woodcraft.me.uk>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: 'adduser --disabled-login' does not behave as documented.

Date: Thu, 05 May 2011 18:56:37 +0100

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-17                    minimal Perl system

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

From: Sam Morris <sam@robots.org.uk>

To: 625758@bugs.debian.org

Subject: Re: 'adduser --disabled-login' does not behave as documented.

Date: Fri, 26 Jul 2013 11:35:12 +0100

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

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

[adduser-disabled-login.patch (text/x-patch, attachment)]

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

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

From: Stephen Gran <sgran@debian.org>

To: Sam Morris <sam@robots.org.uk>, 625758@bugs.debian.org

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

Date: Fri, 26 Jul 2013 19:39:00 +0100

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

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 |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

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

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

From: Sam Morris <sam@robots.org.uk>

To: Stephen Gran <sgran@debian.org>

Cc: 625758@bugs.debian.org

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

Date: Fri, 26 Jul 2013 20:17:51 +0100

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

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 (application/pgp-signature, inline)]

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

From: Stephen Gran <sgran@debian.org>

To: Sam Morris <sam@robots.org.uk>

Cc: 625758@bugs.debian.org

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

Date: Sat, 27 Jul 2013 08:44:55 +0100

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

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 |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

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

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

From: Sam Morris <sam@robots.org.uk>

To: Stephen Gran <sgran@debian.org>

Cc: 625758@bugs.debian.org

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

Date: Sat, 27 Jul 2013 11:43:20 +0100

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

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

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

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

From: Stephen Gran <sgran@debian.org>

To: Sam Morris <sam@robots.org.uk>, 625758@bugs.debian.org

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

Date: Mon, 29 Jul 2013 17:57:42 +0100

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

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 |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

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

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

From: Matti Kurkela <kaukomailla@gmail.com>

To: 625758@bugs.debian.org

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

Date: Thu, 6 Sep 2018 13:38:19 +0300

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.

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

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Matthew Woodcraft <matthew@woodcraft.me.uk>, 625758@bugs.debian.org, 625758-submitter@bugs.debian.org

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

Date: Mon, 7 Mar 2022 22:12:01 +0100

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

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

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Sam Morris <sam@robots.org.uk>, 625758@bugs.debian.org, 625758-submitter@bugs.debian.org

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

Date: Mon, 7 Mar 2022 22:16:51 +0100

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

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

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org

Cc: Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Sat, 19 Mar 2022 11:44:05 +0100

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

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

From: Vincent Lefevre <vincent@vinc17.net>

To: Marc Haber <mh+debian-packages@zugschlus.de>, 625758@bugs.debian.org

Cc: Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Wed, 12 Oct 2022 16:37:22 +0200

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 <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Message #85 received at 625758-submitter@bugs.debian.org (full text, mbox, reply):

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: 625758-submitter@bugs.debian.org

Subject: Bug#625758 marked as pending in adduser

Date: Sun, 25 Dec 2022 16:27:30 +0000

Control: tag -1 pending

Hello,

Bug #625758 in adduser reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/adduser/-/commit/427ade7d9116af5af7baa9d0c538e14fa86560cf

------------------------------------------------------------------------
re-work --disabled-(login|password) as discussed on -devel

Closes: #625758
Thanks: Matthew Woodcraft and Sam Morris
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/625758

Message #92 received at 625758-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 625758-close@bugs.debian.org

Subject: Bug#625758: fixed in adduser 3.130

Date: Sun, 25 Dec 2022 17:49:05 +0000

Source: adduser
Source-Version: 3.130
Done: Marc Haber <mh+debian-packages@zugschlus.de>

We believe that the bug you reported is fixed in the latest version of
adduser, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 625758@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marc Haber <mh+debian-packages@zugschlus.de> (supplier of updated adduser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 25 Dec 2022 17:11:31 +0100
Source: adduser
Architecture: source
Version: 3.130
Distribution: unstable
Urgency: low
Maintainer: Debian Adduser Developers <adduser@packages.debian.org>
Changed-By: Marc Haber <mh+debian-packages@zugschlus.de>
Closes: 243929 344824 579107 625758 1016014 1016913 1020615 1021217 1023836 1025384
Changes:
 adduser (3.130) unstable; urgency=low
 .
   [ Marc Haber ]
 .
   * debian/NEWS: inform about planned deprecations
   * Fully implement and test (first|last)(uid|gid).
     (Closes: #579107, #344824)
   * Implement usage of UID-Pool.
     Thanks to Hilko Bengen and Christoph Biedl (Closes: #243929)
   * More clearly document supplementary group behavior with USERGROUPS=yes.
     This fixes an inconsistency between code, adduser.8 and
     adduser.conf.5. adduser.conf.5. code and tests implement consensus
     reached in summer 2022 in #678615. (Closes: #1025384)
   * Re-work --disabled-(login|password) as discussed on -devel.
     Thanks to Matthew Woodcraft and Sam Morris (Closes: #625758)
   * Add quota to Suggests. Addresses part of #541728.
     Thanks to Christoph Anton Mitterer
   * Change --allow-badname to --allow-bad-names.
     --allow-badname and --force-badname are deprecated but still supported.
   * Deprecate --no-preserve-root.
   * Deprecate --gecos, new option --comment
   * Remove invalidate_nscd calls. (Closes: #1016913)
   * Specialcase /nonexistent so that it never gets created
   * Multiple --conf options are now allowed
   * Sync options in manual pages, help, configuration file and code
   * Be clearer in 'directory already exists' message. Addresses part of #541728.
     Thanks to Christoph Anton Mitterer
   * Manpage re-work
     * Re-word, re-structure, many clarifications, remove ambiguities
     * Sort options
     * Give general options explanation
     * Remove wrong information about sgid bits from adduser.8
     * Fix typos and formatting errors in adduser.8.
       Thanks to Jean-Paul Guillonneau
     * Add test that fails if dangling manpage symlinks are there
     * Semantic linebreaks, lint clean, formatting changes to deluser.conf.5
     * Have po4a accept manpages that are > 95 % translated
   * README:
     * Actually install the file.
       Thanks to Olaf van der Spek (Closes: #1020615)
     * Fix typos. Thanks to Olaf van der Spek
     * Mention no duplication policy from man pages.
   * Move po4a to Build-Depends.
     Thanks to Adam Borowski (Closes: #1021217)
   * Standards-Version: 4.6.2 (no changes necessary)
 .
   [ Jason Franklin ]
   * Use "#! /bin/sh" in the maintainer scripts. (Closes: #1023836)
   * Remove symbolic links for man pages that do not exist. (Closes: #1016014)
 .
   [ Akbarkhon Variskhanov ]
   * adduser.8: Fix formatting issues
 .
   [ Niels Thykier ]
   * Make adduser build without (fake)root
 .
   [ Benjamin Drung ]
   * adduser: Remove trailing newline.
Checksums-Sha1:
 a605f123e96baea8bcf4505324aa23260d0bb38c 1671 adduser_3.130.dsc
 6234b82fb583e959c0921f69a630ba2b29db9c38 239024 adduser_3.130.tar.xz
 08aded8fa43fbd93073a7135b9ed1688ccc8cbca 6086 adduser_3.130_source.buildinfo
Checksums-Sha256:
 d5ab297aab740b1abcc24e20bf4b5534ab26ed1a1b67ee4f5707a9431e96ce2f 1671 adduser_3.130.dsc
 8d0c22438056493972bce5cc0e487826c8e85b5f6c57760a47030126dae5e2e1 239024 adduser_3.130.tar.xz
 cb6d2536c5b98197713f5dc81c8c8cf01931615689034fd699350ab01584a700 6086 adduser_3.130_source.buildinfo
Files:
 e4b2e7b95cc8ac68f67788d72289d05c 1671 admin important adduser_3.130.dsc
 116e8d022c24a16d8ee75adeb9da7288 239024 admin important adduser_3.130.tar.xz
 9392ed2f503ecd5a9c07d71f65b80d1a 6086 admin important adduser_3.130_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE6QL5UJ/L0pcuNEbjj3cgEwEyBEIFAmOohssACgkQj3cgEwEy
BEIh6hAApxXA3QxH6c+H4j/0dCUsiiwU0TQWxIbQVugRDjZ+VfUVIuGFFHlapba4
suWEMPDmUVZcZQXIw5TqgP6vOYYiVGLisjr7nt56wavlC3hhdrem7aBIoYhEABwk
8X/8OIfHaL4lHaF10DkrzwOSk2KDG4zzGk8yZxgN3HHM5ai1CvKufIu2r97cW5Er
5gkEIRB3owiCTQU2IuAANMiNK204XbRIcTGQaziJPcgI5R3cB6Y0AVuZOhTK/BLs
7l49VjBFu+4xe0MSNwxH677ywFVU8nOcAl2nPNqA8kW+YALW3lV+2+Xi3m6nuCLF
C5zk4WSRhFCNmReKpDkcoO5d0BwvKOtvk1PXYd6V+S7f6p3lX41gxYgesXbyi4Cn
Cn1HYohgFOsrvfCATIR537Ep/0Mfm0Qz/C81tbp/j0xKR+dSwd9/v93dQE239K/K
a5I3G1r/nObDZZj/BXB/w1cNEIe1pMTuWHJ9GHbpFMDsAra340pTXgTK96qivNBc
Rtj4pcjWQ9gkdt8hL1v9ilj7hIoqZdtltBT6FyMvwCWMyO9s0SC49g+xxj7DyLQ2
AZf4CYtlDPhb7Bo5ZrTzlHftwTLh6g/qgV+jEm83G5FpO/ydJiLeC20Ga64SjIYk
sbreWAC4mLFec3iXJbn1pd7SsK6+0s3R3o4CGcIaFwDIBNPkJ2s=
=VV85
-----END PGP SIGNATURE-----

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

From: Colin Watson <cjwatson@debian.org>

To: Marc Haber <mh+debian-packages@zugschlus.de>, 625758@bugs.debian.org

Cc: 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Mon, 2 Jan 2023 23:04:22 +0000

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)                              [cjwatson@debian.org]

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

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Colin Watson <cjwatson@debian.org>

Cc: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Tue, 3 Jan 2023 15:04:22 +0100

Hi Colin,

On Mon, Jan 02, 2023 at 11:04:22PM +0000, 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

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

From: Colin Watson <cjwatson@debian.org>

To: Marc Haber <mh+debian-packages@zugschlus.de>

Cc: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Tue, 3 Jan 2023 18:17:36 +0000

On Tue, Jan 03, 2023 at 03:04:22PM +0100, Marc Haber wrote:
> On Mon, Jan 02, 2023 at 11:04:22PM +0000, 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)                              [cjwatson@debian.org]

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

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Colin Watson <cjwatson@debian.org>

Cc: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Thu, 5 Jan 2023 15:36:18 +0100

Hi Colin,

On Tue, Jan 03, 2023 at 06:17:36PM +0000, 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

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

From: Timo Lindfors <timo.lindfors@iki.fi>

To: Marc Haber <mh+debian-packages@zugschlus.de>

Cc: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Tue, 17 Jan 2023 17:22:19 +0200 (EET)

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

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

From: Marc Haber <mh+debian-packages@zugschlus.de>

To: Timo Lindfors <timo.lindfors@iki.fi>

Cc: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Wed, 18 Jan 2023 09:33:17 +0100

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

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

From: Timo Lindfors <timo.lindfors@iki.fi>

To: Marc Haber <mh+debian-packages@zugschlus.de>

Cc: 625758@bugs.debian.org, 625758-submitter@bugs.debian.org, Matthew Woodcraft <matthew@woodcraft.me.uk>

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

Date: Wed, 18 Jan 2023 21:12:28 +0200 (GMT+02:00)

Jan 18, 2023 11:35:43 Marc Haber <mh+debian-packages@zugschlus.de>:
> 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.

Send a report that this bug log contains spam.