Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#625758: 'adduser --disabled-login' does not behave as documented.
370 views
Skip to first unread message
Matthew Woodcraft
May 5, 2011, 2:30:02 PM5/5/11
to
Package: adduser
Version: 3.112+nmu2
Severity: normal
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
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Matti Kurkela
Sep 6, 2018, 6:50:02 AM9/6/18
to
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.
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.
Marc Haber
Mar 7, 2022, 4:20:02 PM3/7/22
to
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
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.
> --disabled-password
> Like --disabled-login, but logins are still possible (for exam‐
> ple using SSH RSA keys) but not using password authentication.
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
Marc Haber
Mar 19, 2022, 6:50:03 AM3/19/22
to
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
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.
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
Vincent Lefevre
Oct 12, 2022, 10:40:04 AM10/12/22
to
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
> - 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.
--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 <vin...@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)
Colin Watson
Jan 2, 2023, 6:10:04 PM1/2/23
to
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
> 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.
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) [cjwa...@debian.org]
Marc Haber
Jan 3, 2023, 9:10:03 AM1/3/23
to
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
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.
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.)
environment that Debian installed. Isn't that somewaht the idea of
testing?
> However,
> it could affect systems where the admin has disabled UsePAM.
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;
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.
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
Colin Watson
Jan 3, 2023, 1:30:03 PM1/3/23
to
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.
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?
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?
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.)
Marc Haber
Jan 5, 2023, 9:40:04 AM1/5/23
to
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.
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?
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.
> > 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.)
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.
Timo Lindfors
Jan 17, 2023, 10:30:03 AM1/17/23
to
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
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
Marc Haber
Jan 18, 2023, 3:40:03 AM1/18/23
to
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
> 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?
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
Timo Lindfors
Jan 18, 2023, 2:20:04 PM1/18/23
to
Jan 18, 2023 11:35:43 Marc Haber <mh+debian...@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.
> cannot login.
0 new messages