Re: Seeking consensus for some changes in adduser
Hi,
this is the summary follow-up to the adduser discussion we had in the
last eight days, and I hope that I was successful in working all of your
suggestions in the new text.
Original Message Text:
> (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).
The answer to question (1a) is yes.
A possible consensus would be to augment the DIR_MODE setting with a
SYSTEM_DIR_MODE setting that would apply to --system accounts, allowing
to handle system accounts and user accounts in a different way.
The answer to question (1b) is "yes, as the default".
The default of SYSTEM_DIR_MODE would be 0755, and we would document that
changing this default setting might affect the function of the system
since most packages expect their account's home directory to have mode
0755. This gives the local administrator maximum freedom while not
requiring changes to packages and keeping their behavior in sync with
policy. If SYSTEM_DIR_MODE is too restrictive, some packages will break,
if it's too permissive, some packages will become insecure. I do intend
to have SYSTEM_DIR_MODE in the manual page, but not in the default
configuration file.
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).
Currently, on a freshly installed system, /root is root:root 0700 and
has umask 022, while normal user accounts have their /home/user
user:user 0755 and have umask 022 as well.
While the root group is somewhat special (my brain refuses to consider
this a regular usergroup), I think that having /root restrictive is a
good example of what we actually want. The user having their own
per-user group AND
I have checked that if /home/user is 0700, the entire subtree under
/home/user is unaccessible and the system doesn't care any more what the
permissions of the directories under /home/user are. This is something I
keep getting wrong so I wanted to be sure.
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?
(1e) has become a uncommon configuration, so we don't need to cater for
that any more by default. Users expert enough to have a public_html
directory can be held responsible to appropriately set up permissions
and/or ACLs.
I have a new question. Currently, adduser has a single Debconf question
regarding system-wide readable home directories. Should we take the
opportunity of removing this question and just assuming that a local
administrator will reset DIR_MODE if they feel like that? The caveat of
this is that the value can no longer be preseeded in the installer, but
that will only affect the _single_ account created during installation.
I feel that this may be worth the reduced complexity. What do you think?
> (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.
Adduser should be more orthogonal in handling of system and user
accounts. The following paragraphs describe how adduser should behave in
my opinion, and if it doesn't do right now, it will be changed.
There should be different regexp settings to define which account names
are allowed for system and user accounts. Both regexps should be
configurable at run time, and there should be command line options to
override the check. If overridden, the checks are disabled in their
entirety, relying on underlying tools (useradd) to reject really
unacceptable names.
For system accounts, the allowed chars are an optional leading
underscore, lower case letters, numbers, underscores, dashes. This means
that packages using names like Debian-exim or Foo will need to keep
their override-option active like today, but new packages using a system
account like _apt can use that name without having to override our
checks.
We still have packages using the dot syntax in chown shell scripts.
There is a new Lintian check to warn for that now, but I don't think
that Debian is ready today to allow dots in user names right now. Local
administrators who need a more permissive regexp for their local users
might change NAME_REGEX and take some responsibility to file bugs
against packages that break with that relaxed setting, but in the
default user accounts will still have to restrain themselves to ASCII
letters (lower and upper case), numbers, underscores, dashes, with
leading underscores not being allowed by the default regexp.
> (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)?
--disabled-password will result in a "*" in /etc/shadow, effectively
making it impossible to use any password based authentication. This will
also suppress the setting of a password during creation of a user
account, which we currently do by just calling passwd and leaving the
work to the subprocess.
--disabled-login will set the login shell to /usr/sbin/nologin,
disabling the account for most usages. This needs changes to the
documentation, we will do that and write an appropriate NEWS.Debian
entry as this may be relevant.
No other changes to options are planned in this regard.
Adduser does not support changing the password of an account that
already exists, there are no plans to change this.
> (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"?
I do plan to set the default for DIR_MODE to have the setgid set and to
change SETGID_HOME to yes. SETGID_HOME is redundant if DIR_MODE exists,
so this is going to be deprecated, removed from the docs in trixie and
from the code in trixie+1.
I think it is safe to assume that the "bad side effects" mentioned in
the configuration file are historic and non longer relevant here.
> (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?
This can be answered together, I plan to change EXTRA_GROUPS to just
contain "users" in the future. I am trying this setting on my personal
systems now.
What was not in the primary discussion:
deluser will grow a --lock option that will replace a user's shell with
/usr/bin/nologin.
There will be a configuration option chanding deluser's default behavior
to not actually delete a --system account but lock it.
That way, a package can call deluser --lock in postrm for remove, and
straight deluser in postrm for purge, while leaving the final decision
what should happen with system accounts on purge to the local
administrator. The default for said configuration option will depend on
the outcome of #1006912 which tries to change/adapt policy in this
regard.
Thank you for your time.
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
Reply to: