(2)
#774046 #520037
Which special characters should we allow for account names?
For system-accounts, I'd like to stick to ASCII letters, numbers, underscores.
(3)
#625758
--disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh.
On Tue, 08 Mar 2022 at 17:49:04 +0100, Marc Haber wrote:
(2)
#774046 #520037
Which special characters should we allow for account names?
For system-accounts, I'd like to stick to ASCII letters, numbers,
underscores.
ASCII letters, numbers, underscores and dashes (U+002D HYPHEN-MINUS),
I hope? Lots of system accounts already use dashes, notably www-data
in the base-passwd set.
"Marc" == Marc Haber <mh+debian-devel@zugschlus.de> writes:
Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3
According to the history of that patch, we have some old consensus to
move toward usergroups and a default umask of 0002 (except for root
which gets 0022).
...
(2)
#774046 #520037
Which special characters should we allow for account names?
People demand being able to use a dot (which might break scripts using
chown) and non-ASCII national characters in account names. The regex
used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time.
For system-accounts, I'd like to stick to ASCII letters, numbers, underscores.
...
Greetings
Marc
(1)
#202943, #202944, #398793, #442627, #782001
The bug reporters are requesting the default for DIR_MODE to be changed
from 0755 to 0700, making home directories readable for the user only.
Policy 10.9 states that directories should be 0755, but the policy
editors probably didn't have user home directories in mind when they
wrote that.
(1a) would it be necessary to handle --system accounts differently? I
think yes. > (1b) should we stay with 0755 for --system accounts?
(1c) does a change to 0700 for user accounts make sense?
(1d) should it be 0751 (#398793)?
(1e) how about ~/public_html that would break with 0750?
All those bugs referenced have more or less heated exchanges ranging
from "it's fine" to "we should issue a DSA ASAP", most of them a decade
old, so the times might have changed since then. Please note that the DIR_MODE _IS_ configurable in adduser, we're just discussing the
default (which also applies for home directories created while still
inside the Installer before a local admin can properly configure
adduser).
(2)
#774046 #520037
Which special characters should we allow for account names?
People demand being able to use a dot (which might break scripts using
chown) and non-ASCII national characters in account names. The regex
used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time.
For system-accounts, I'd like to stick to ASCII letters, numbers, underscores.
(3)
#625758
--disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing change to document reality
should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
(4)It's probably of minimal benefit. Assuming the user's home directory
#979385 #248130
The default for SETGID_HOME is =no, with a comment from the last century
that states that the default was changed from yes to no because of "bad
side effects" this had. Does anybody have an idea which bad side effects could be meant by that, and what would we possibly break by changing the default to "yes"?
(5)
#678615
should all newly created non-system users be added to the users group
even on a system with userprivate groups (as it is the default)?
(6)
#849265, https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html
Should we really empty out the extra_groups list default?
On 3/8/22 10:49, Marc Haber wrote:
(1)
#202943, #202944, #398793, #442627, #782001
The bug reporters are requesting the default for DIR_MODE to be changed from 0755 to 0700, making home directories readable for the user only. Policy 10.9 states that directories should be 0755, but the policy
editors probably didn't have user home directories in mind when they
wrote that.
As a data point, Ubuntu moved to 750 a year ago: https://ubuntu.com/blog/private-home-directories-for-ubuntu-21-04
At my day job, we then followed that across the board (despite not yet
being on an Ubuntu release where the change was made), and it was
essentially fine. We already considered home directories on our file
server to be "private", and on everything else, there are only accounts
for admins (who can use sudo in the rare event they need a file from
someone else's home directory).
(1a) would it be necessary to handle --system accounts differently? I
think yes. > (1b) should we stay with 0755 for --system accounts?
I don't see why system accounts need to be different.
(1c) does a change to 0700 for user accounts make sense?
Yes.
(1d) should it be 0751 (#398793)?
Pro: That helps ~/public_html.
Con: That seems like a trap for non-expert users. It _feels_ like other people can't get at things, but they actually can, if they know the next directory down. I (and probably everyone reading this list) understands
the "1" in 751, but do end users?
(1e) how about ~/public_html that would break with 0750?
As a comment on the bug mentioned, public_html not a default thing.
Changing DIR_MODE and/or ACLs are also options for those who want a ~/public_html concept.
All those bugs referenced have more or less heated exchanges ranging
from "it's fine" to "we should issue a DSA ASAP", most of them a decade old, so the times might have changed since then. Please note that the DIR_MODE _IS_ configurable in adduser, we're just discussing the
default (which also applies for home directories created while still
inside the Installer before a local admin can properly configure
adduser).
I think there is merit to defaulting to the most secure (but still reasonable) option, and letting people loosen it if desired.
(2)
#774046 #520037
Which special characters should we allow for account names?
People demand being able to use a dot (which might break scripts using chown) and non-ASCII national characters in account names. The regex
used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time.
For system-accounts, I'd like to stick to ASCII letters, numbers, underscores.
I support dashes, as was already discussed. That's already in use.
I think the idea of dot in a username is perfectly reasonable on its
own. For some people this is very desirable. My wife, for example, uses
a dot in her email username as her first name plus my-now-her last
initial makes a word that is awkward. (This sort of problem is not
uncommon in usernames, especially at companies that make them via some algorithm.)
I always use colon for chown, which is what is documented, but I'm aware
it takes dot too. Is there any code in chown to handle the dot case intelligently?
Non-ASCII does feel a little concerning to me (since those code paths
won't be exercised very often).
But to recognize my bias, I have no need for a non-ASCII username. I'd probably feel quite differently if my name wasn't correctly
representable in ASCII. Put differently, if usernames were currently
required to be Han or Cyrillic characters, I'd certainly be up in arms
asking for Latin character support.
On the other hand, Debian probably can't go it alone here. If, as people
have mentioned, systemd isn't going to support those usernames, there's
not much point in adduser allowing them.
(3)
#625758
--disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing change to document reality
Simon McVittie's explanation matches my understanding of what the
current behaviors of '*' and '!' are (but I haven't tested the empty
password nuance).
While I get the general idea of locking in a way that allows unlocking
later (and keeping the original password hash), I don't see
--disabled-login as being particularly useful for adduser, since it
leads to an identical result as --disabled-password.
should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
I wouldn't add another option. I think --disabled-password is fine. Just keeping that reduces the amount of change people need to make.
I'd probably just document --disabled-login as being deprecated and functionally equilvalent to --disabled-password.
(4)It's probably of minimal benefit. Assuming the user's home directory
#979385 #248130
The default for SETGID_HOME is =no, with a comment from the last century that states that the default was changed from yes to no because of "bad side effects" this had. Does anybody have an idea which bad side effects could be meant by that, and what would we possibly break by changing the default to "yes"?
group is set to the user's primary group, in practice we end up with the
same result.
I can't immediately think of a problem. Generally when I'm setting an explicit group on some directory for humans to put files in, g+s is desirable.
(5)
#678615
should all newly created non-system users be added to the users group
even on a system with userprivate groups (as it is the default)?
Yes.
(6)
#849265, https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html
Should we really empty out the extra_groups list default?
With the exception of users, I wouldn't expect adduser to put people in special groups by default. If those groups do nothing, I guess it's
moot. But in principle (and in the past), those groups give special permissions and I would NOT expect that, nor want that.
--
Richard
(1a) would it be necessary to handle --system accounts differently? I
think yes.
I think it would be helpful to define "system account" and "normal user". Neither adduser(8) nor useradd(8) provide a sufficient definition,
especially wrt the existing network directory services (LDAP, AD, etc).
Is a "system user" supposed to be a local account, defined in /etc/passwd only?
Related question: How are naming collisions between local entries and
the entries in a network directory service supposed to be handled?
On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote:
...
(2)
#774046 #520037
Which special characters should we allow for account names?
People demand being able to use a dot (which might break scripts using
chown) and non-ASCII national characters in account names. The regex
used to verify non-system accounts is configurable, so the policy can be
locally relaxed at run-time.
For system-accounts, I'd like to stick to ASCII letters, numbers,
underscores.
...
There is a DD with the login 93sam, and this is already outside of
what systemd accepts.[1]
Non-ASCII characters in account names sound like a lot of breakage
and CVEs to me.
On Tue, Mar 8, 2022 at 6:18 PM Richard Laager <rlaager@debian.org> wrote: >Please add support for "." so we can use first.last names as user
names. Other Linux's are already doing this so it should not break
anything.
On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote:
Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3
According to the history of that patch, we have some old consensus to
move toward usergroups and a default umask of 0002 (except for root
which gets 0022).
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or as a default).
(Though I think the current world-readable by default is already quite
bad. It seems like a unsafe choice on both single-user and multi-user >systems...)
On 2022-03-08 17:49:04, Marc Haber wrote:
(1a) would it be necessary to handle --system accounts differently? I
think yes.
I think it would be helpful to define "system account" and "normal user". >Neither adduser(8) nor useradd(8) provide a sufficient definition,
especially wrt the existing network directory services (LDAP, AD, etc).
Is a "system user" supposed to be a local account, defined in /etc/passwd >only?
Related question: How are naming collisions between local entries and
the entries in a network directory service supposed to be handled?
Something like
passwd: files sss
in /etc/nsswitch.conf is not helpful, if a postinst script fails to
create a local account due to the entry it has found in freeipa, for
example. Not to mention that such a service might fail at boot time,
if the directory service is not available (yet).
On Tue, 08 Mar 2022 at 17:49:04 +0100, Marc Haber wrote:
(3)
#625758
--disabled-password just does not set a password for the newly created
account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh.
I assume you mean: allowing login via ssh if other steps have been taken
to allow it, like creating and populating ~/.ssh/authorized_keys?
This ties in with the suggestion that system accounts should be "locked" >(usermod -L -e 1) when the package that owns them is removed.
usermod -L
edits the crypted password in /etc/shadow to prevent login, by prepending >'!', which is not a possible crypt(3) output: so it seems the distinction >between these options is something like:
--disabled-password: the new account doesn't have a valid password, so >password authentication will always fail
--disabled-login: the new account has an empty password but is "locked";
so password authentication will fail, but "unlocking" the account will
result in login being accepted with a blank password (subject to other >policies like ssh PermitEmptyPasswords and PAM nullok)
(3)
#625758
--disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing change to document reality, should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
I don't think it makes sense to move toward 0700 home directories and to >loosen the umask for usergroups.
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager <rlaager@debian.org>
wrote:
I think the idea of dot in a username is perfectly reasonable on its
own. For some people this is very desirable. My wife, for example, uses
a dot in her email username as her first name plus my-now-her last
initial makes a word that is awkward. (This sort of problem is not
uncommon in usernames, especially at companies that make them via some >>algorithm.)
I always use colon for chown, which is what is documented, but I'm aware
it takes dot too. Is there any code in chown to handle the dot case >>intelligently?
How would chown handle the dot case intelligently? At the moment, the
chown manpage doesn't contain the words "dot" or "period", but chown >root.root some-file will do the same like chown root:root some-file,
changing user and group.
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
(2)
#774046 #520037
Which special characters should we allow for account names?
On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote:
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
Setting a default ACL on project directories seems a technical better >solution for this problem.
It would only affect permissions of files
that should intentionally be group-readable, not all files created
anywhere.
On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote:
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
Setting a default ACL on project directories seems a technical better >solution for this problem. It would only affect permissions of files
that should intentionally be group-readable, not all files created
anywhere.
If the admin can change the default DIR_MODE that applies to system user
home directories, then any postinst script doing `adduser --system`
needs to also explicitly chmod its home directory if it needs anything
more permissive than 700 or more restrictive than 755. This is true
today and remains true whether or not the default DIR_MODE is changed.
How would chown handle the dot case intelligently?
Something along the lines of see if the user exists.
Are we using ACLs [by] Default already in other places of the Debian
system?
On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote:
Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3
According to the history of that patch, we have some old consensus to
move toward usergroups and a default umask of 0002 (except for root
which gets 0022).
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or as a default).
(Though I think the current world-readable by default is already quite
bad. It seems like a unsafe choice on both single-user and multi-user systems...)
On Wed, 9 Mar 2022 14:10:04 +0100, Harald Dunkel
Related question: How are naming collisions between local entries and
the entries in a network directory service supposed to be handled?
Something like
passwd: files sss
in /etc/nsswitch.conf is not helpful, if a postinst script fails to
create a local account due to the entry it has found in freeipa, for
example. Not to mention that such a service might fail at boot time,
if the directory service is not available (yet).
That is beyond adduser's scope. We're (as the adduser team) usually
weasel out of that topic by saying that a system refering to a
directory service is run by skilled staff, and we expect those people
to do their job. It's a small team, adduser has been in limbo for
years, so we need to concentrate on the traps that a novice or
unexperiences user might fall into while relying on skilled users to
work around the issues that we haven't found the time to fix.
However, I suspect that something is a bit broken about this anyway,
since I just tested and get a umask of 0022 when logging in via ssh
to a system with USERGROUPS_ENAB 'yes'.
On Thu, 10 Mar 2022 at 06:37:58 +0100, Marc Haber wrote:
Are we using ACLs [by] Default already in other places of the Debian
system?
For user-facing purposes I don't think so (although they're available to >anyone who wants to set them),
On Tue, 8 Mar 2022 18:40:11 +0000, Simon McVittie <smcv@debian.org> >--disabled-login: the new account has an empty password but is "locked";
so password authentication will fail, but "unlocking" the account will >result in login being accepted with a blank password (subject to other >policies like ssh PermitEmptyPasswords and PAM nullok)
that way, --disabled-login doesnt sound desireable at all, it would
violate the principle of least surprise at least for me. I'd have
expected (and always believed) that a password of ! will also prevent
ssh-key logins from happening.
This is another trap: /etc/login.defs seems to define some ranges for >"system" uids and gids. They are commented out by default, nevertheless
they imply some configurability. Are changes in login.defs supposed to
be respected by all packages, including passwd (useradd) and adduser?
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or as a default).
AFAIK systems that don't use usergroups are already not running in
standard Debian configuration, since we default to USERGROUPS_ENAB being 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).
❦ 10 March 2022 11:21 +01, Philip Hands:
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or as a default).
AFAIK systems that don't use usergroups are already not running in
standard Debian configuration, since we default to USERGROUPS_ENAB being
'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).
Has it always been the case? On my oldest system, my primary group is "users".
On systems that don't use usergroups for all/some users, doesn't this
change make all files writable by other users by default? That would
seem like a very unsecure change on upgrades (or as a default).
AFAIK systems that don't use usergroups are already not running in
standard Debian configuration, since we default to USERGROUPS_ENAB being >>> 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf).
Has it always been the case? On my oldest system, my primary group is "users".
It was always configurable, but was enabled out of the box in hamm...
On Wed, Mar 09, 2022 at 09:00:22PM +0100, Marc Haber wrote:
On Tue, 8 Mar 2022 18:40:11 +0000, Simon McVittie <smcv@debian.org>
--disabled-login: the new account has an empty password but is "locked";
so password authentication will fail, but "unlocking" the account will
result in login being accepted with a blank password (subject to other
policies like ssh PermitEmptyPasswords and PAM nullok)
that way, --disabled-login doesnt sound desireable at all, it would
violate the principle of least surprise at least for me. I'd have
expected (and always believed) that a password of ! will also prevent
ssh-key logins from happening.
I don't see how that follows from Simon's statement? AIUI, he's saying
that that is true *until" you unlock the account (which essentially
means dropping the "!" from the passwd file).
Am I misreading something here?
❦ 10 March 2022 11:34 -05, Michael Stone:
It was always configurable, but was enabled out of the box in hamm...
My system was installed on Potato if I remember correctly (or maybe
Woody, but definitely not older than Potato). But maybe my home was
imported from a SuSE installation and I tweaked something.
Considering many have replied, I'll stick to that one:
Marc Haber <mh+debian-devel@zugschlus.de> wrote on 08/03/2022 at 17:49:04+0100:
(3)
#625758
--disabled-password just does not set a password for the newly created
account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing
change to document reality, should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
How about --disabled-login => shell is set to /usr/sbin/nologin ?
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to >>loosen the umask for usergroups.
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
This was changed in coreutils to be posix-compliant more than 20 years
ago. The spec is that chown accepts user:group syntax, and chown will
always first attempt to split on ":". If there is no :, chown will try to >resolve the whole argument as a username (that is, regardless of whether >there's a "."). If the username isn't resolvable *and* it contains a
".", it will try to split on the first "." and use the left side as the >username and the right side as the group. So *only if* someone attempts
to use a dot-containing username in chown without a : and the
dot-containing username is invalid, then it might be interpreted as a >user.group spec.
Now, if someone is trying to actually use user.group
syntax rather than the user:group syntax that's been standard for 20+
years, that will definitely break in the presence of dot-containing >usernames.
Given how common such usernames are on other systems, I'd
expect the breakage to be minimal by now, and a bug in anything still
using that syntax. We could make coreutils print a deprecation warning,
but that's never really been useful in the past; probably better to just >error out any time a . is used for something other than a valid username
and drop the 20+ year old compatability code.
On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote:
(2)
#774046 #520037
Which special characters should we allow for account names?
Please consider the leading character separately from the rest of the >characters:
- leading digits sometimes causes programs to parse a 'username' as an
'user id' instead; you can see some of this here:
https://github.com/systemd/systemd/issues/6237
I know I've seen more instances of this over the years.
- leading dash may cause the username to be treated as command line
options in some programs. I've lost references to this happening.
While you can argue these are bugs in the programs involved, they do
happen in the wild. Thus, I'd like to suggest that the regex be more >restrictive for the first character.
On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar <ansgar@43-1.org> wrote:
On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote:
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
Setting a default ACL on project directories seems a technical better >solution for this problem. It would only affect permissions of files
that should intentionally be group-readable, not all files created >anywhere.
Are we using ACLs bei Default already in other places of the Debian
system?
I have re-read Simon's words and still have the interpretation that
unlocking an account that has been created with -disabled-login will
allow login without password, making the account completely open.
On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bécue
<peb@debian.org> wrote:
Considering many have replied, I'll stick to that one:
Marc Haber <mh+debian-devel@zugschlus.de> wrote on 08/03/2022 at 17:49:04+0100:
(3)
#625758
--disabled-password just does not set a password for the newly created
account (resulting in '*' in shadow) while --disabled-login places a '!' >>> in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing
change to document reality, should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
How about --disabled-login => shell is set to /usr/sbin/nologin ?
I have noted that as one of the options for my summary. I assume that
in that case, the password should still be * to avoid creating an
active unlocked account with empty password?
Greetings
- leading digits sometimes causes programs to parse a 'username' as an
'user id' instead; you can see some of this here:
https://github.com/systemd/systemd/issues/6237
I know I've seen more instances of this over the years.
- leading dash may cause the username to be treated as command line
options in some programs. I've lost references to this happening.
Should those two restrictions apply for both system and user accounts?
Should they be overrideable?
On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bcue
<peb@debian.org> wrote:
Considering many have replied, I'll stick to that one:
Marc Haber <mh+debian-devel@zugschlus.de> wrote on 08/03/2022 at 17:49:04+0100:
(3)
#625758
--disabled-password just does not set a password for the newly created
account (resulting in '*' in shadow) while --disabled-login places a '!' >> in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing
change to document reality, should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
How about --disabled-login => shell is set to /usr/sbin/nologin ?
I have noted that as one of the options for my summary. I assume that
in that case, the password should still be * to avoid creating an
active unlocked account with empty password?
On Thu, Mar 10, 2022 at 06:37:58AM +0100, Marc Haber wrote:
On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar <ansgar@43-1.org> wrote:
On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote:
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
Setting a default ACL on project directories seems a technical better
solution for this problem. It would only affect permissions of files
that should intentionally be group-readable, not all files created
anywhere.
Are we using ACLs bei Default already in other places of the Debian
system?
We are using filesystem capabilities; and as far as I'm aware we have no >filesystems that support fscaps extended attributes but NOT acls, nor am I >aware of any archive formats that would preserve fscaps without also >preserving acls.
On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone <mstone@debian.org>
wrote:
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to >>>loosen the umask for usergroups.
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared >>directories can be anywhere, and are likely *not* in a single user's
home.
Hence, no change needed in adduser? Or is that an argument for having >DIR_MODE=0700 in default?
This was changed in coreutils to be posix-compliant more than 20 years
ago. The spec is that chown accepts user:group syntax, and chown will >>always first attempt to split on ":". If there is no :, chown will try to >>resolve the whole argument as a username (that is, regardless of whether >>there's a "."). If the username isn't resolvable *and* it contains a
".", it will try to split on the first "." and use the left side as the >>username and the right side as the group. So *only if* someone attempts
to use a dot-containing username in chown without a : and the >>dot-containing username is invalid, then it might be interpreted as a >>user.group spec.
Now, if someone is trying to actually use user.group
syntax rather than the user:group syntax that's been standard for 20+ >>years, that will definitely break in the presence of dot-containing >>usernames.
... but just in the case that the same string exists both as the last >component of a dot-containing user name AND as a group name. All other
cases are defined.
How would the spec listed above behave for user names with more than
one dot?
Given how common such usernames are on other systems, I'd
expect the breakage to be minimal by now, and a bug in anything still
using that syntax. We could make coreutils print a deprecation warning,
but that's never really been useful in the past; probably better to just >>error out any time a . is used for something other than a valid username >>and drop the 20+ year old compatability code.
Do you want a coreutils bug to error out in the case of user.group
notation in chown? I guess it's due time. Would we go alone in Debian
or would you prefer that we try convincing upstream to finally go that
way? I am not convinced that Debian should derive from standard
behavior here, but you have the coreutils hat on and I would support
either decision.
usermod: unlocking the user's password would result in a passwordless account.
You should set a password with usermod -p to unlock this user's password.
+1 to --disabled-login setting the shell to /usr/sbin/nologin with >documentation being updated to reflect this. I'd suggest a default
behavior of a password of '*', with the ability to override it and
prompt for a real password with a "--set-password". Although honestly,
I also wouldn't be opposed to requiring an extra step of calling
'usermod' to set a password for a disabled account. It's sort of a
special case, and not one that has to be explicitly handled by adduser.
I don't have a really strong preference either way. Maybe carry a patch
until just before freeze to bubble stuff up during testing? Maybe allow
an environment variable to override (either way?) to facilitate testing?
The problem is that the systems most likely to blow up (because they're
using ancient scripts) are also really unlikely to suddenly start using
dot usernames, so breaking them for the sake of correctness on other
systems seems gratuitous. If there isn't already, maybe some kind of
lintian script check (though that seems probably challenging for static >analysis)? In the end, there are already so many ways to shoot yourself
in the foot with shell scripts if you don't follow all the disorganized
rules every single time that letting this be the reason to disallow dot >usernames seems extreme.
wishlist bug for a lintian check.
times in Debian, mostly in docs and comments, but also in a few live
scripts. I think that we still have some way to go until we get rid of
the dot notation in chown calls.
On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote: >>[^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829
times in Debian, mostly in docs and comments, but also in a few live >>scripts. I think that we still have some way to go until we get rid of
the dot notation in chown calls.
It also has to be a variable; if it's "root.root" or such, it doesn't
matter.
And remember, there are existing real-world debian systems that have
users with dots (regardless of local adduser policy; think ldap/ad for >example) so these are already issues that either need to be fixed or
don't really matter.
It also has to be a variable; if it's "root.root" or such, it doesn't
matter.
On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone <mstone@debian.org>
wrote:
And remember, there are existing real-world debian systems that have
users with dots (regardless of local adduser policy; think ldap/ad for >>example) so these are already issues that either need to be fixed or
don't really matter.
Yes, they need to be fixed, but it's a different can of beer if we
cannot say "hey, you changed our default, so you get to keep the
pieces of what got broken" but have to say "oops".
"Marc" == Marc Haber <mh+debian-devel@zugschlus.de> writes:
Let me try asking something more reasonable.
If you end up tightening down world readableness, let me know so I can
reject the umask patch, because I suspect if your decision to tighten
down being world readable sticks, the 15 year old usergroups decision
would need to be revalidated by someone who cared.
(1)
#202943, #202944, #398793, #442627, #782001
The bug reporters are requesting the default for DIR_MODE to be changed
from 0755 to 0700, making home directories readable for the user only.
Policy 10.9 states that directories should be 0755, but the policy
editors probably didn't have user home directories in mind when they
wrote that.
(1a) would it be necessary to handle --system accounts differently? I
think yes.
(1b) should we stay with 0755 for --system accounts?
(1c) does a change to 0700 for user accounts make sense?
(1d) should it be 0751 (#398793)?
(1e) how about ~/public_html that would break with 0750?
All those bugs referenced have more or less heated exchanges ranging
from "it's fine" to "we should issue a DSA ASAP", most of them a decade
old, so the times might have changed since then. Please note that the DIR_MODE _IS_ configurable in adduser, we're just discussing the
default (which also applies for home directories created while still
inside the Installer before a local admin can properly configure
adduser).
(2)
#774046 #520037
Which special characters should we allow for account names?
People demand being able to use a dot (which might break scripts using
chown) and non-ASCII national characters in account names. The regex
used to verify non-system accounts is configurable, so the policy can be locally relaxed at run-time.
For system-accounts, I'd like to stick to ASCII letters, numbers, underscores.
(3)
#625758
--disabled-password just does not set a password for the newly created account (resulting in '*' in shadow) while --disabled-login places a '!'
in shadow. On modern systems with PAM, both variants seem to be
identical, allowing login via ssh. Aside from the documentation needing change to document reality, should we introduce a --no-set-password
option and deprecate the two older options (to be removed in trixie+2)?
(4)
#979385 #248130
The default for SETGID_HOME is =no, with a comment from the last century
that states that the default was changed from yes to no because of "bad
side effects" this had. Does anybody have an idea which bad side effects could be meant by that, and what would we possibly break by changing the default to "yes"?
(5)
#678615
should all newly created non-system users be added to the users group
even on a system with userprivate groups (as it is the default)?
(6)
#849265, https://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/2017-January/032300.html
Should we really empty out the extra_groups list default?
My post-discussion answer to question (1c) is yes, but I am still open
for arguments. If noone convinces me, the default for DIR_MODE will be changed to 2700 (see (4) below).
(...)
A setgid bit on a non-group-readable directory might seem strange
though. Are there arguments against doing so aside from the ugly "S" in
ls output?
... Here is what the adduser team considers possible
documentation for this, and we itend to include this in NEWS.Debian as a rationale for the change.
Marc Haber <mh+debian-devel@zugschlus.de> writes:
... Here is what the adduser team considers possible
documentation for this, and we itend to include this in NEWS.Debian
as a
rationale for the change.
As a user who reads NEWS.Debian (via apt-listchanges) i found the
text
didnt give me the answers i was looking for. I wanted to know:
- what had changed (and when)
- why has a change been made
- how the change might affects my existing/new systems - eg do i need
to
manually do something to adopt it?
- how/if i can customise/revert/use the new changes?
I also found the end of the draft was written almost combatively - as
a
user i dont really care about bug reports or whether developers
argued
on a mailing list: i just want to know the facts and whether i need
to
do anything different as a result. A more neutral phrasing would be
better and would also go out-of-date slower.
Most NEWS files suffer from this to some extent but i was hoping for something with less about bug reports and more like:
"adduser version 3.122 has changed
pppppp (DIR_MODE setting in /etc/???? ) from aaa to bbb (one of these
is
0700 i think, but i couldnt tell which?).
- why has a change been made
I think this is explained in excruciating detail. The short version
(from NEWS):
"mode 0700 provides both the most secure, unsurprising default"
Matt Barry <matt@hazelmollusk.org> writes:[...]
- why has a change been made
I think this is explained in excruciating detail. The short version
(from NEWS):
"mode 0700 provides both the most secure, unsurprising default"
And the claim that this is "most unsurprising" (less surprising?) is obviously false. "No change" is always less surprising than any change, whatever the rationale is.
On 25.07.22 08:46, Bjørn Mork wrote:
Matt Barry <matt@hazelmollusk.org> writes:[...]
- why has a change been made
I think this is explained in excruciating detail. The short version
(from NEWS):
"mode 0700 provides both the most secure, unsurprising default"
And the claim that this is "most unsurprising" (less surprising?) is
obviously false. "No change" is always less surprising than any change,
whatever the rationale is.
It can also be unsurprising from an end-user's perspective. For
someone new to the system. So that line of argument does not really
hold.
Philipp Kern <pkern@debian.org> writes:
On 25.07.22 08:46, Bjørn Mork wrote:
obviously false. "No change" is always less surprising than any
change,
whatever the rationale is.
It can also be unsurprising from an end-user's perspective. For
someone new to the system. So that line of argument does not really
hold.
True. Good point.
I was reading this as "unsuprising to the reader (system operator)",
but
I see that it could mean "unsusprising to the system users". Which
would make more sense.
Is there a limit to the size of these entries which makes it hard to
be
more precise?
Anyway, its been released at this point, so the issue is moot :)
On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote:
On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote:
Anyway, its been released at this point, so the issue is moot :)
Regardless of the rest of the discussion, this isn't entirely true.
Yes, people following unstable will have already seen the NEWS entry
and
apt-listchanges won't show it again for that version, but it's still possible to edit it retroactively so that (for example) people
upgrading
between stable releases see improved text. That can sometimes be worthwhile.
That is a good point, and probably something we should plan to do.
Matt Barry wrote:
On Mon, 2022-07-25 at 14:37 +0100, Colin Watson wrote:
On Sun, Jul 24, 2022 at 12:34:31PM -0400, Matt Barry wrote:
Anyway, its been released at this point, so the issue is moot :)
Regardless of the rest of the discussion, this isn't entirely true.
Yes, people following unstable will have already seen the NEWS entry
and
apt-listchanges won't show it again for that version, but it's still
possible to edit it retroactively so that (for example) people
upgrading
between stable releases see improved text. That can sometimes be
worthwhile.
That is a good point, and probably something we should plan to do.
In particular, it may make sense to edit this NEWS entry and the
previous one, to avoid presenting two entries to stable users for two >different successive changes, rather than just one effective change.
I don't like the idea of messing with old NEWS entries at all.
In this case, an exception might be warranted, but we need to have the
long explanation somewhere in the package for the next round of this
issue that is expected in the 2030ies.
On Mon, Jul 25, 2022 at 07:06:59PM +0200, Marc Haber wrote:
I don't like the idea of messing with old NEWS entries at all.
I'm trying to understand why you feel this way.
We implemented that change last week, and promptly a bug report
(#1014901) appeared, giving what we consider good arguments to change
this back to 0700. Here is what the adduser team considers possible documentation for this, and we itend to include this in NEWS.Debian as a rationale for the change.
[...]
As mode 0700 provides both the most secure, unsurprising default, and is
in line with most other major distributions, the adduser team considers
the matter to be settled; any further discussion should come prepared
with rationale, support, convincing use cases and a significant public discussion period.
Ubuntu changed the default DIR_MODE to 0750 in January 2021 [1] with the
same intention than Debian now. I like to see Debian and Ubuntu agree on
one default DIR_MODE to keep the package difference small and make documentation shareable.
Since users have their own primary group, it makes more sense to
have this users group have read access. So people can easily add users
to other users groups to give them read access. I read through the mails
on Debian and found no mentioning about 0750 (and therefore no reason
against it). Therefore I suggest to change the default permission for
users from 0700 to 0750.
[1] https://launchpad.net/bugs/48734
On Tue, 2022-07-19 at 08:49 +0200, Marc Haber wrote:
We implemented that change last week, and promptly a bug report
(#1014901) appeared, giving what we consider good arguments to change
this back to 0700. Here is what the adduser team considers possible
documentation for this, and we itend to include this in NEWS.Debian as a
rationale for the change.
[...]
As mode 0700 provides both the most secure, unsurprising default, and is
in line with most other major distributions, the adduser team considers
the matter to be settled; any further discussion should come prepared
with rationale, support, convincing use cases and a significant public
discussion period.
Ubuntu changed the default DIR_MODE to 0750 in January 2021 [1] with the
same intention than Debian now. I like to see Debian and Ubuntu agree on
one default DIR_MODE to keep the package difference small and make >documentation shareable.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 26:37:12 |
| Calls: | 6,707 |
| Calls today: | 1 |
| Files: | 12,239 |
| Messages: | 5,352,567 |