On Tue, Mar 8, 2022 at 6:18 PM Richard Laager <rlaa...@debian.org> wrote: > > 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?
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. > 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 >
