Re: Seeking consensus for some changes in adduser
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager <rlaager@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
I still see Ubuntu as targeted heavily at end-user systems used by
beginners. I don't think that all decisions that are good for Ubuntu
are good for Debian as well.
>> (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.
avahi-daemon has /var/run/avahi-daemon as its home directory and
places its socket there. I'd guess that having this directory not
accessible for the world will kind of influence the usability of the
daemon. We have many packages that are configured like that.
dnsmask even has /var/lib/misc as home, which is not even owned by the
account, so setting that one to 0750 would probably be even more
destructive.
No, that's trying too much.
>> (1c) does a change to 0700 for user accounts make sense?
>
>Yes.
Can we get consensus on that?
>> (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?
Point.
>> (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.
A webserver serving userdirs should be in the hands of a competent
admin, right?
>> 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.
Point.
>> (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?
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.
>Non-ASCII does feel a little concerning to me (since those code paths
>won't be exercised very often).
I think they would in non-latin countries.
>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.
Yes, that's my feeling as well.
otoh, adduser can already be configured to be more relaxed for user
accounts, so you can have an all-cyrillic user name already today,
adduser doesnt even need to be massaged to allow that.
>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.
Imagine a file server that the user will never actually log in to but
still own files.
>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.
locking should probably be done by adding * to an already existing
passwd hash in /etc/shadow. I do not intend to have adduser mess with
internals this deep but instead rely on what password and shadow offer
documented interfaces for.
>I'd probably just document --disabled-login as being deprecated and
>functionally equilvalent to --disabled-password.
Noted as a possible outcome. Thanks!
I have made notes of your other comments, which I wildly appreciate.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: