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
