Re: Seeking consensus for some changes in adduser
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)
#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"?
It's probably of minimal benefit. Assuming the user's home directory
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
Reply to: