Re: Seeking consensus for some changes in adduser
On Mon, 28 Nov 2022 15:50:56 +, Benjamin Drung wrote: >On Tue, 2022-07-19 at 08:49 +0200, Marc Haber wrote: >> We implemented that change last week, and promptly a bug report >> (#1014901) appeared, giving what we consider good arguments to change >> this back to 0700. Here is what the adduser team considers possible >> documentation for this, and we itend to include this in NEWS.Debian as a >> rationale for the change. >> >> [...] >> >> As mode 0700 provides both the most secure, unsurprising default, and is >> in line with most other major distributions, the adduser team considers >> the matter to be settled; any further discussion should come prepared >> with rationale, support, convincing use cases and a significant public >> discussion period. > >Ubuntu changed the default DIR_MODE to 0750 in January 2021 [1] with the >same intention than Debian now. I like to see Debian and Ubuntu agree on >one default DIR_MODE to keep the package difference small and make >documentation shareable. See NEWS.Debian for adduser 3.123 and the "default for DIR_MODE" chapter in https://salsa.debian.org/debian/adduser/-/blob/master/debian/README ¹. I am tired of this discussion and will not change this decision until overridden by the ctte. Greetings Marc ¹ the next upload will have this README actually installed to the package, I apologize for this bug -- -- !! 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
Re: Seeking consensus for some changes in adduser
On Mon, 2022-11-28 at 15:50 +, Benjamin Drung wrote: > Ubuntu changed the default DIR_MODE to 0750 in January 2021 [1] with the > same intention than Debian now. I like to see Debian and Ubuntu agree on > one default DIR_MODE to keep the package difference small and make > documentation shareable. > > Since users have their own primary group, it makes more sense to > have this users group have read access. So people can easily add users > to other users groups to give them read access. I read through the mails > on Debian and found no mentioning about 0750 (and therefore no reason > against it). Therefore I suggest to change the default permission for > users from 0700 to 0750. > > [1] https://launchpad.net/bugs/48734 That does not seem to be a good idea to me. The user-specific groups exist so umask != 077 can work in some way. Adding other users to the group bypasses that and I think should not to recommended to be used. If you use umask 007[2] because that seems safe with usergroups, it suddenly is not. If people insist on doing that, they can still change the permissions of their home directory. But I don't think this is a good argument for changing the default (rather the opposite). Ansgar [2]: For example taken from man:pam_umask(8) for the usergroups option.
Re: Seeking consensus for some changes in adduser
Hi, sorry for being so late in the discussion. On Tue, 2022-07-19 at 08:49 +0200, Marc Haber wrote: > We implemented that change last week, and promptly a bug report > (#1014901) appeared, giving what we consider good arguments to change > this back to 0700. Here is what the adduser team considers possible > documentation for this, and we itend to include this in NEWS.Debian as a > rationale for the change. > > [...] > > As mode 0700 provides both the most secure, unsurprising default, and is > in line with most other major distributions, the adduser team considers > the matter to be settled; any further discussion should come prepared > with rationale, support, convincing use cases and a significant public > discussion period. Ubuntu changed the default DIR_MODE to 0750 in January 2021 [1] with the same intention than Debian now. I like to see Debian and Ubuntu agree on one default DIR_MODE to keep the package difference small and make documentation shareable. Since users have their own primary group, it makes more sense to have this users group have read access. So people can easily add users to other users groups to give them read access. I read through the mails on Debian and found no mentioning about 0750 (and therefore no reason against it). Therefore I suggest to change the default permission for users from 0700 to 0750. [1] https://launchpad.net/bugs/48734 -- Benjamin Drung Debian & Ubuntu Developer
adduser default for sgid home directories (was: Seeking consensus for some changes in adduser)
Back in March, I wrote in , https://lists.debian.org/debian-devel/2022/03/msg00304.html: > 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). > > (...) > > 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? We implemented that change last week, and promptly a bug report (#1014901) appeared, giving what we consider good arguments to change this back to 0700. Here is what the adduser team considers possible documentation for this, and we itend to include this in NEWS.Debian as a rationale for the change. Please comment. Suggested Documentation Text Follows: In adduser 3.122, we implemented code that allows setting the default for the mode bits of the home directory of a newly created system user independently of the mode bits of the home directory of a newly created non-system user (SYS_DIR_MODE vs DIR_MODE). This was in part done to finally solve #643559, which requested setting the sgid bit for the home directory of a non-system user by default, in order to ease setting access permissions of shared workspaces in multi-user systems. This default has oscillated back in forth in adduser multiple times since the 1990ies, because both ways to set this bit by default have advantages and disadvantages. After a preliminary request for comment (see https://lists.debian.org/debian-devel/2022/03/msg00098.html), the default value for DIR_MODE was changed to 2700 in adduser 3.122 (July 2022). Sadly, though the technical reasoning for NOT setting the bit have largely not survived the last two decades, here remain some use cases impacted by the change which we were not fully aware of. Promptly, #1014901 was filed, requesting that DIR_MODE be changed to 0700, effectively causing home directories of non-system users to be created without the sgid bit. The biggest point in the reasoning is that having the sgid bit set will need special measures to keep the home directory's group ownership from propagating to file system images, chroots, and archives, causing wrong file ownership/permissions in those entities, which in turn might propagate to different systems and cause security-related effects there. The bug report gives instructions to reproduce the behavior. System administrators who run multi-user environments which require shared workspaces have tools at their disposal to change the default behavior as their individual needs require, and likely are aware of how to work around any issues that arise as part of that configuration; it is also very possible that such systems may be managed using configuration management software. In an age of general purpose use on one end, and single purpose containers on the other, this is unlikely to be the majority of newly installed systems. So what remains is the decision to provide a sane default for a system that is installed by an end-user, who may not understand or be aware of this setting at all, but who still might use Internet HOW-TOs to build chroots, images or archives, inadvertently causing security issues on third-party systems. The clear and unsurprising solution is to leave the sgid bit for newly created users off by default. This is also important to keep the support effort for other packages down. Users surprised by the behavior might file bugs against other packages, increasing the effort necessary to support those other packages. In adduser 3.123, DIR_MODE will be changeed to 0700, flipping the default for the sgid bit once again to the value we have had for the majority of Debian's existence period. With this change, Debian is re-joining ranks again with ALL other major Linux distributions, none of which setting the sgid bit on home directories to 1 (research done in July 2022). As the root user and its home directory is created by other means, this primarily affects the one user that can be created in the Installer before there is any possibility to configure adduser. Those users will now again have the sgid bit of the home directory set to 0. Again, system administrators have the tools and documentation to configure their systems as their individual requirements dictate (using DIR_MODE, and/or fixing those initial directories). As mode 0700 provides both the most secure, unsurprising default, and is in line with most other major distributions, the adduser team considers the matter to be settled; any further discussion should come prepared with rationale, support, convincing use cases and a significant public discussion period. 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
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,
Re: Seeking consensus for some changes in adduser
On Sun, 13 Mar 2022 20:52:47 -0600, Sam Hartman wrote: >Let me try asking something more reasonable. >If you end up tightening down world readableness, let me know so I can >reject the umask patch, because I suspect if your decision to tighten >down being world readable sticks, the 15 year old usergroups decision >would need to be revalidated by someone who cared. Wouldnt the umask patch be even more useful if we tightened down the directory permissions? 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
Re: Seeking consensus for some changes in adduser
> "Marc" == Marc Haber writes: >> But I'd ask you to look into the history of usergroups in Debian >> as part of your decision process. Marc> Where would I read up on that? I am not deeply enough in those Marc> political things to be able to judge whether a discussion from Marc> 15 years ago is still valid today. No clue either. Let me try asking something more reasonable. If you end up tightening down world readableness, let me know so I can reject the umask patch, because I suspect if your decision to tighten down being world readable sticks, the 15 year old usergroups decision would need to be revalidated by someone who cared.
Re: Seeking consensus for some changes in adduser
On Sun, Mar 13, 2022 at 11:09:24AM +0100, Marc Haber wrote: On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone wrote: And remember, there are existing real-world debian systems that have users with dots (regardless of local adduser policy; think ldap/ad for example) so these are already issues that either need to be fixed or don't really matter. Yes, they need to be fixed, but it's a different can of beer if we cannot say "hey, you changed our default, so you get to keep the pieces of what got broken" but have to say "oops". I don't think we can say that now, unless we also say that all the tools we have for integrating with external directory services shouldn't be used, and also retroactively change the documentation for adduser.conf to say that you shouldn't use the characters that the man page says you can. In general debian doesn't just say "hey, you changed our default, so you get to keep the pieces of what got broken" for configurations documented as valid.
Re: Seeking consensus for some changes in adduser
On Sat, 2022-03-12 at 14:41 -0500, Michael Stone wrote: > It also has to be a variable; if it's "root.root" or such, it doesn't > matter. But that could be confused with a user named "root.root" instead of user "root" + group "root" as intended. So this would need to be changed to use root:root as well. (Not that I would recommend having a user with this name.) Ansgar
Re: Seeking consensus for some changes in adduser
On Sat, 12 Mar 2022 14:41:35 -0500, Michael Stone wrote: >On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote: >>[^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829 >>times in Debian, mostly in docs and comments, but also in a few live >>scripts. I think that we still have some way to go until we get rid of >>the dot notation in chown calls. > >It also has to be a variable; if it's "root.root" or such, it doesn't >matter. It matters if coreutils will at some time remove the dot notation, making chown root.root an error. And I surely hope that this is the end of the road we're progressing on. >And remember, there are existing real-world debian systems that have >users with dots (regardless of local adduser policy; think ldap/ad for >example) so these are already issues that either need to be fixed or >don't really matter. Yes, they need to be fixed, but it's a different can of beer if we cannot say "hey, you changed our default, so you get to keep the pieces of what got broken" but have to say "oops". 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
Re: Seeking consensus for some changes in adduser
On Fri, Mar 11, 2022 at 10:16:24PM +0100, Marc Haber wrote: [^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829 times in Debian, mostly in docs and comments, but also in a few live scripts. I think that we still have some way to go until we get rid of the dot notation in chown calls. It also has to be a variable; if it's "root.root" or such, it doesn't matter. I did a similar search, mostly found false positives (e.g., perl or ruby scripts not actually calling chown(1). The one real example I found in a cursory glance is from /usr/bin/humfsify in uml-utilities...but it's also an example of my point about "so many ways to break shell scripts if you don't follow every semi-documented rule every time": find file_metadata -type d | xargs chown $user.$group so, yeah, that'll break if $user has a dot--but it's already broken if there's a file/directory with a space. So are dots the straw that breaks the camel's back? And remember, there are existing real-world debian systems that have users with dots (regardless of local adduser policy; think ldap/ad for example) so these are already issues that either need to be fixed or don't really matter.
Re: Seeking consensus for some changes in adduser
Hi, On Fri, Mar 11, 2022 at 1:16 PM Marc Haber wrote: > > wishlist bug for a lintian check. Implemented in Lintian, and pending for the next release: https://salsa.debian.org/lintian/lintian/-/commit/66ea726de5f34cf693b7d01a297f495abf650588 Thank you, everyone, for your comments! Kind regards Felix Lechner
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 17:38:20 -0800, Noah Meyerhans wrote: >+1 to --disabled-login setting the shell to /usr/sbin/nologin with >documentation being updated to reflect this. I'd suggest a default >behavior of a password of '*', with the ability to override it and >prompt for a real password with a "--set-password". Although honestly, >I also wouldn't be opposed to requiring an extra step of calling >'usermod' to set a password for a disabled account. It's sort of a >special case, and not one that has to be explicitly handled by adduser. Noted. I will post a summary at the beginning of the new week. 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
Re: Seeking consensus for some changes in adduser
On Fri, 11 Mar 2022 10:45:50 -0500, Michael Stone wrote: >I don't have a really strong preference either way. Maybe carry a patch >until just before freeze to bubble stuff up during testing? Maybe allow >an environment variable to override (either way?) to facilitate testing? >The problem is that the systems most likely to blow up (because they're >using ancient scripts) are also really unlikely to suddenly start using >dot usernames, so breaking them for the sake of correctness on other >systems seems gratuitous. If there isn't already, maybe some kind of >lintian script check (though that seems probably challenging for static >analysis)? In the end, there are already so many ways to shoot yourself >in the foot with shell scripts if you don't follow all the disorganized >rules every single time that letting this be the reason to disallow dot >usernames seems extreme. [^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]] is found 829 times in Debian, mostly in docs and comments, but also in a few live scripts. I think that we still have some way to go until we get rid of the dot notation in chown calls. This would be a nice idea for an MBF. Sadly I do not have the time to do that. I have filed a wishlist bug for a lintian check. 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
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
Am 11.03.22 um 15:37 schrieb Simon McVittie: and the equivalent if we were relying on sysusers would be this: install flatpak /usr/lib/sysusers.d/flatpak.conf is created postinst or trigger invokes systemd-sysusers An important distinction is that this postinst can be generated easily instead of having to be written manually. Actually, we do that already via the dh_systemdsysusers dh addon. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 09:33:00PM +0100, Marc Haber wrote: On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone wrote: On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote: I don't think it makes sense to move toward 0700 home directories and to loosen the umask for usergroups. Those are actually unrelated--the big reason for the more permissive umask is to allow people to seamlessly work with other people in a group, especially within setgid shared directories. Those shared directories can be anywhere, and are likely *not* in a single user's home. Hence, no change needed in adduser? Or is that an argument for having DIR_MODE=0700 in default? It's simply a statement that the default mode for home directories and the default umask are separate decisions. This was changed in coreutils to be posix-compliant more than 20 years ago. The spec is that chown accepts user:group syntax, and chown will always first attempt to split on ":". If there is no :, chown will try to resolve the whole argument as a username (that is, regardless of whether there's a "."). If the username isn't resolvable *and* it contains a ".", it will try to split on the first "." and use the left side as the username and the right side as the group. So *only if* someone attempts to use a dot-containing username in chown without a : and the dot-containing username is invalid, then it might be interpreted as a user.group spec. Now, if someone is trying to actually use user.group syntax rather than the user:group syntax that's been standard for 20+ years, that will definitely break in the presence of dot-containing usernames. ... but just in the case that the same string exists both as the last component of a dot-containing user name AND as a group name. All other cases are defined. How would the spec listed above behave for user names with more than one dot? It splits on the first dot, which is why scripts could break. E.g., if you use user.group syntax and user happens to be us.er, then you end up trying to use us.er.group and that will fail. Semi-randomly, for whichever users happen to have dots, so it'll be a pain to debug. Given how common such usernames are on other systems, I'd expect the breakage to be minimal by now, and a bug in anything still using that syntax. We could make coreutils print a deprecation warning, but that's never really been useful in the past; probably better to just error out any time a . is used for something other than a valid username and drop the 20+ year old compatability code. Do you want a coreutils bug to error out in the case of user.group notation in chown? I guess it's due time. Would we go alone in Debian or would you prefer that we try convincing upstream to finally go that way? I am not convinced that Debian should derive from standard behavior here, but you have the coreutils hat on and I would support either decision. I don't have a really strong preference either way. Maybe carry a patch until just before freeze to bubble stuff up during testing? Maybe allow an environment variable to override (either way?) to facilitate testing? The problem is that the systems most likely to blow up (because they're using ancient scripts) are also really unlikely to suddenly start using dot usernames, so breaking them for the sake of correctness on other systems seems gratuitous. If there isn't already, maybe some kind of lintian script check (though that seems probably challenging for static analysis)? In the end, there are already so many ways to shoot yourself in the foot with shell scripts if you don't follow all the disorganized rules every single time that letting this be the reason to disallow dot usernames seems extreme.
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
On Mar 11, Simon Richter wrote: > We currently don't have a good mechanism for leaving configuration behind on > purge, which we've historically done with user accounts to avoid reuse of > UIDs that may own resources, so we'd still have to create the declarations > from a postinst. While this is a reasonable concern I do not think that it is generally true nowadays for system processes. Also thanks to piuparts, nowadays packages that leave files around after being purged should be a really small number. Actually I cannot think of any, so this should be considered the exception rather than the norm. So I totally support transitioning to systemd-sysusers. -- ciao, Marco signature.asc Description: PGP signature
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
On Fri, 11 Mar 2022 at 12:08:27 +0100, Simon Richter wrote: > On 3/10/22 8:59 PM, Michael Biebl wrote: > > have you considered a more declarative approach as provided by > > systemd-sysusers (8)? > > We currently don't have a good mechanism for leaving configuration behind on > purge, which we've historically done with user accounts to avoid reuse of > UIDs that may own resources, so we'd still have to create the declarations > from a postinst. Why would that be desirable? systemd-sysusers isn't a NSS plugin that magics users into existence without them existing (unlike libnss-systemd, which is part of the implementation of DynamicUser). Instead, systemd-sysusers reads its declarative source files and uses them to populate the state of the system user database (in practice that usually means /etc/passwd). If the user already exists in the system user database, then it won't go away just because the source file was removed. Using flatpak as my example of a "modern" package that creates a system user (which is named _flatpak as per Policy §9.2.1), what we currently do is: install flatpak postinst invokes adduser adduser adds _flatpak to /etc/passwd remove flatpak nothing special happens _flatpak continues to exist in /etc/passwd (some packages use usermod -L here, but I'm not clear on what benefit that provides, so flatpak currently doesn't) purge flatpak nothing special happens _flatpak continues to exist in /etc/passwd and the equivalent if we were relying on sysusers would be this: install flatpak /usr/lib/sysusers.d/flatpak.conf is created postinst or trigger invokes systemd-sysusers systemd-sysusers adds _flatpak to /etc/passwd remove flatpak /usr/lib/sysusers.d/flatpak.conf is removed _flatpak continues to exist in /etc/passwd purge flatpak nothing special happens _flatpak continues to exist in /etc/passwd In fact flatpak already installs /usr/lib/sysusers.d/flatpak.conf - partly because its upstream developer wants to support distros that already rely on sysusers to manage system uids, partly as a small step towards stateless systems being able to boot with an empty /etc, and partly as a way to document in a declarative way that flatpak "owns" the _flatpak account. It doesn't currently make use of that file in the postinst, because Policy recommends using adduser (imperatively), but it could if we wanted to. On a system where flatpak has ever been installed (even if it was subsequently removed), the only situation in which the _flatpak user would cease to exist would be if it was explicitly removed from /etc/passwd, perhaps as part of a "factory reset" procedure. If that happens, I think the correct behaviour would be to recreate it (if flatpak is still installed and still needs it) or leave it absent (otherwise) - which is what systemd-sysusers would "naturally" do on the next reboot, if left to do its job. smcv
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
Hi, On 3/10/22 8:59 PM, Michael Biebl wrote: have you considered a more declarative approach as provided by systemd-sysusers (8)? We currently don't have a good mechanism for leaving configuration behind on purge, which we've historically done with user accounts to avoid reuse of UIDs that may own resources, so we'd still have to create the declarations from a postinst. Simon OpenPGP_signature Description: OpenPGP digital signature
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
On Thu, 10 Mar 2022 20:59:50 +0100, Michael Biebl wrote: >have you considered a more declarative approach as provided by >systemd-sysusers (8)? No. This thread is about evolving adduser. Not getting rid of it. 514 packages in Debian match "adduser.*--system". Feel free to offer a declarative thing and encourage maintainers to migrate. adduser is going to continue to offer a stable interface for existing packages for the time being. It has been adduser's goal for 20 years now to be as declarative as possible in a maintainer script by doing everything necessary, just requiring the package to have one line in the right place in the script. Greetings Marc P.S.: I got involved with adduser 20 years ago because the then debhelper maintainer brushed off my suggestion to have a dh call for creating system users. Back then, this approach was as declarative as it could get. -- -- !! 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
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 13:17:26 -0800, Steve Langasek wrote: >On Thu, Mar 10, 2022 at 06:37:58AM +0100, Marc Haber wrote: >> On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar wrote: >> >On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: >> >> Those are actually unrelated--the big reason for the more permissive >> >> umask is to allow people to seamlessly work with other people in a >> >> group, especially within setgid shared directories. Those shared >> >> directories can be anywhere, and are likely *not* in a single user's >> >> home. > >> >Setting a default ACL on project directories seems a technical better >> >solution for this problem. It would only affect permissions of files >> >that should intentionally be group-readable, not all files created >> >anywhere. > >> Are we using ACLs bei Default already in other places of the Debian >> system? > >We are using filesystem capabilities; and as far as I'm aware we have no >filesystems that support fscaps extended attributes but NOT acls, nor am I >aware of any archive formats that would preserve fscaps without also >preserving acls. Is this usage in a place that a user would consciously have to interface with? I still raise my eyebrow when I see that "+" somewhere. 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
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 09:35:27PM +0100, Marc Haber wrote: > On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bécue > wrote: > >Considering many have replied, I'll stick to that one: > >Marc Haber wrote on 08/03/2022 at > >17:49:04+0100: > >> (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)? > > > >How about --disabled-login => shell is set to /usr/sbin/nologin ? > > I have noted that as one of the options for my summary. I assume that > in that case, the password should still be * to avoid creating an > active unlocked account with empty password? +1 to --disabled-login setting the shell to /usr/sbin/nologin with documentation being updated to reflect this. I'd suggest a default behavior of a password of '*', with the ability to override it and prompt for a real password with a "--set-password". Although honestly, I also wouldn't be opposed to requiring an extra step of calling 'usermod' to set a password for a disabled account. It's sort of a special case, and not one that has to be explicitly handled by adduser. noah
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 09:37:49PM +0100, Marc Haber wrote: > >- leading digits sometimes causes programs to parse a 'username' as an > > 'user id' instead; you can see some of this here: > > https://github.com/systemd/systemd/issues/6237 > > I know I've seen more instances of this over the years. > > > >- leading dash may cause the username to be treated as command line > > options in some programs. I've lost references to this happening. > > Should those two restrictions apply for both system and user accounts? > Should they be overrideable? I think both restrictions should apply to both system and user accounts, and allowing an admin to override this is perfectly fine; we can't know the full set of requirements at every site. Thanks signature.asc Description: PGP signature
Re: Seeking consensus for some changes in adduser
Marc Haber wrote on 10/03/2022 at 21:35:27+0100: > On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bécue > wrote: >>Considering many have replied, I'll stick to that one: >>Marc Haber wrote on 08/03/2022 at >>17:49:04+0100: >>> (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)? >> >>How about --disabled-login => shell is set to /usr/sbin/nologin ? > > I have noted that as one of the options for my summary. I assume that > in that case, the password should still be * to avoid creating an > active unlocked account with empty password? > > Greetings If you set /usr/sbin/nologin as the shell, any interactive usage of the account is locked for good. Of course, you could still fetch mails or things like that if the machine provides imap accounts for unix accounds, but then I'd guess someone eager to avoid that would use --disabled-password combined with --disabled-login. Altering the password with --disabled-login seems counterintuitive to me, but I'd still be fine with it. -- PEB signature.asc Description: PGP signature
Re: systemd-sysusers [Re: Seeking consensus for some changes in adduser]
On Thu, 10 Mar 2022 at 20:24, Michael Biebl wrote: > > Hi Marc, > > have you considered a more declarative approach as provided by > systemd-sysusers (8)? > > I'm a fan of less manual maintainer scripts code and maybe > systemd-sysusers is an answer to that, especially given that we split > out the systemd-sysusers binary into a standalone binary which should > help facilitate that. > > Regards, > Michael +1 for declarative approach Kind regards, Luca Boccassi
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 06:37:58AM +0100, Marc Haber wrote: > On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar wrote: > >On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: > >> Those are actually unrelated--the big reason for the more permissive > >> umask is to allow people to seamlessly work with other people in a > >> group, especially within setgid shared directories. Those shared > >> directories can be anywhere, and are likely *not* in a single user's > >> home. > >Setting a default ACL on project directories seems a technical better > >solution for this problem. It would only affect permissions of files > >that should intentionally be group-readable, not all files created > >anywhere. > Are we using ACLs bei Default already in other places of the Debian > system? We are using filesystem capabilities; and as far as I'm aware we have no filesystems that support fscaps extended attributes but NOT acls, nor am I aware of any archive formats that would preserve fscaps without also preserving acls. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 00:01:36 +, Seth Arnold wrote: >On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote: >> (2) >> #774046 #520037 >> Which special characters should we allow for account names? > >Please consider the leading character separately from the rest of the >characters: > >- leading digits sometimes causes programs to parse a 'username' as an > 'user id' instead; you can see some of this here: > https://github.com/systemd/systemd/issues/6237 > I know I've seen more instances of this over the years. > >- leading dash may cause the username to be treated as command line > options in some programs. I've lost references to this happening. Should those two restrictions apply for both system and user accounts? Should they be overrideable? >While you can argue these are bugs in the programs involved, they do >happen in the wild. Thus, I'd like to suggest that the regex be more >restrictive for the first character. Noted. 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
Re: Seeking consensus for some changes in adduser
On Wed, 09 Mar 2022 21:34:33 +0100, Pierre-Elliott Bécue wrote: >Considering many have replied, I'll stick to that one: >Marc Haber wrote on 08/03/2022 at 17:49:04+0100: >> (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)? > >How about --disabled-login => shell is set to /usr/sbin/nologin ? I have noted that as one of the options for my summary. I assume that in that case, the password should still be * to avoid creating an active unlocked account with empty password? 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
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 17:29:01 -0500, Michael Stone wrote: >On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote: >>I don't think it makes sense to move toward 0700 home directories and to >>loosen the umask for usergroups. > >Those are actually unrelated--the big reason for the more permissive >umask is to allow people to seamlessly work with other people in a >group, especially within setgid shared directories. Those shared >directories can be anywhere, and are likely *not* in a single user's >home. Hence, no change needed in adduser? Or is that an argument for having DIR_MODE=0700 in default? >This was changed in coreutils to be posix-compliant more than 20 years >ago. The spec is that chown accepts user:group syntax, and chown will >always first attempt to split on ":". If there is no :, chown will try to >resolve the whole argument as a username (that is, regardless of whether >there's a "."). If the username isn't resolvable *and* it contains a >".", it will try to split on the first "." and use the left side as the >username and the right side as the group. So *only if* someone attempts >to use a dot-containing username in chown without a : and the >dot-containing username is invalid, then it might be interpreted as a >user.group spec. >Now, if someone is trying to actually use user.group >syntax rather than the user:group syntax that's been standard for 20+ >years, that will definitely break in the presence of dot-containing >usernames. ... but just in the case that the same string exists both as the last component of a dot-containing user name AND as a group name. All other cases are defined. How would the spec listed above behave for user names with more than one dot? > Given how common such usernames are on other systems, I'd >expect the breakage to be minimal by now, and a bug in anything still >using that syntax. We could make coreutils print a deprecation warning, >but that's never really been useful in the past; probably better to just >error out any time a . is used for something other than a valid username >and drop the 20+ year old compatability code. Do you want a coreutils bug to error out in the case of user.group notation in chown? I guess it's due time. Would we go alone in Debian or would you prefer that we try convincing upstream to finally go that way? I am not convinced that Debian should derive from standard behavior here, but you have the coreutils hat on and I would support either decision. And then we'd have to decide whether adduser may allow dot-containing user names before coreutils made this change. 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
systemd-sysusers [Re: Seeking consensus for some changes in adduser]
Hi Marc, have you considered a more declarative approach as provided by systemd-sysusers (8)? I'm a fan of less manual maintainer scripts code and maybe systemd-sysusers is an answer to that, especially given that we split out the systemd-sysusers binary into a standalone binary which should help facilitate that. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 06:28:57PM +0100, Vincent Bernat wrote: ❦ 10 March 2022 11:34 -05, Michael Stone: It was always configurable, but was enabled out of the box in hamm... My system was installed on Potato if I remember correctly (or maybe Woody, but definitely not older than Potato). But maybe my home was imported from a SuSE installation and I tweaked something. Likely--a number of other distributions went with a common user group as I recall.
Re: Seeking consensus for some changes in adduser
On 3/9/22 23:47, Marc Haber wrote: On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager wrote: If the admin can change the default DIR_MODE that applies to system user home directories, then any postinst script doing `adduser --system` needs to also explicitly chmod its home directory if it needs anything more permissive than 700 or more restrictive than 755. This is true today and remains true whether or not the default DIR_MODE is changed. Anything that NEEDS to be written in postinst scripts is bad. I'd rather implement a SYSTEM_DIR_MODE setting that applies to directories created during creation of a --system user. Would that help with the issue? Yes that would _help_, as that would allow the system administrator to change DIR_MODE without changing SYSTEM_DIR_MODE. However, if SYSTEM_DIR_MODE is configurable, you end up with the same problem: unless a given package can work with _any_ reasonable mode (700 to 755), it must explicitly set its own mode. Otherwise, if the administrator sets SYSTEM_DIR_MODE to something too restrictive (scenario A below), some packages will break; if they set it too permissive, some packages will become insecure (scenario B). Having a hardcoded default for system users would at least allow packages certainty, and those that were happy with the default would not need to chmod. Further, my assumption is that there are two different scenarios: A) The system user's home directory needs to be open. For example, if there is a socket in there that needs to be world-writable, which I think you were talking about. B) The system user's home directory needs to be private. For example, there is sensitive data in there. (Another, perhaps better, answer is that the _files_ should have restricted permissions.) _If_ it is the case that both of these scenarios exist, then no single value (default or hardcoded) can satisfy both. So the default should either be the most common mode, or the most restrictive (reasonable) mode. This should probably be my last email on this subtopic. Hopefully I've conveyed my points for your consideration. I don't feel that I'm an expert on the use of system users in Debian. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
❦ 10 March 2022 11:34 -05, Michael Stone: On systems that don't use usergroups for all/some users, doesn't this change make all files writable by other users by default? That would seem like a very unsecure change on upgrades (or as a default). >>> >>> AFAIK systems that don't use usergroups are already not running in >>> standard Debian configuration, since we default to USERGROUPS_ENAB being >>> 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). >> >>Has it always been the case? On my oldest system, my primary group is "users". > > It was always configurable, but was enabled out of the box in hamm... My system was installed on Potato if I remember correctly (or maybe Woody, but definitely not older than Potato). But maybe my home was imported from a SuSE installation and I tweaked something. -- Don't use conditional branches as a substitute for a logical expression. - The Elements of Programming Style (Kernighan & Plauger)
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 05:06:32PM +0100, Vincent Bernat wrote: ❦ 10 March 2022 11:21 +01, Philip Hands: On systems that don't use usergroups for all/some users, doesn't this change make all files writable by other users by default? That would seem like a very unsecure change on upgrades (or as a default). AFAIK systems that don't use usergroups are already not running in standard Debian configuration, since we default to USERGROUPS_ENAB being 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). Has it always been the case? On my oldest system, my primary group is "users". It was always configurable, but was enabled out of the box in hamm...
Re: Seeking consensus for some changes in adduser
❦ 10 March 2022 11:21 +01, Philip Hands: >> On systems that don't use usergroups for all/some users, doesn't this >> change make all files writable by other users by default? That would >> seem like a very unsecure change on upgrades (or as a default). > > AFAIK systems that don't use usergroups are already not running in > standard Debian configuration, since we default to USERGROUPS_ENAB being > 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). Has it always been the case? On my oldest system, my primary group is "users". -- Don't patch bad code - rewrite it. - The Elements of Programming Style (Kernighan & Plauger)
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 11:19:56 +0100, Harald Dunkel wrote: >This is another trap: /etc/login.defs seems to define some ranges for >"system" uids and gids. They are commented out by default, nevertheless >they imply some configurability. Are changes in login.defs supposed to >be respected by all packages, including passwd (useradd) and adduser? fwiw, adduser has never been interested in this configuration. the login.defs(5) manpage says that it is the "shadow password suite configuration". I am not sure whether adduser should honor that configuration. At least both configurations are in sync to each other. Would it make sense that adduser reads login.defs if the respective setting is not overridden in adduser.conf? 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
Re: Seeking consensus for some changes in adduser
On 2022-03-09 21:00:20, Marc Haber wrote: On Wed, 9 Mar 2022 14:10:04 +0100, Harald Dunkel Related question: How are naming collisions between local entries and the entries in a network directory service supposed to be handled? Something like passwd: files sss in /etc/nsswitch.conf is not helpful, if a postinst script fails to create a local account due to the entry it has found in freeipa, for example. Not to mention that such a service might fail at boot time, if the directory service is not available (yet). That is beyond adduser's scope. We're (as the adduser team) usually weasel out of that topic by saying that a system refering to a directory service is run by skilled staff, and we expect those people to do their job. It's a small team, adduser has been in limbo for years, so we need to concentrate on the traps that a novice or unexperiences user might fall into while relying on skilled users to work around the issues that we haven't found the time to fix. This is another trap: /etc/login.defs seems to define some ranges for "system" uids and gids. They are commented out by default, nevertheless they imply some configurability. Are changes in login.defs supposed to be respected by all packages, including passwd (useradd) and adduser? Regards Harri
Re: Seeking consensus for some changes in adduser
On Thu, 2022-03-10 at 11:21 +0100, Philip Hands wrote: > However, I suspect that something is a bit broken about this anyway, > since I just tested and get a umask of 0022 when logging in via ssh > to a system with USERGROUPS_ENAB 'yes'. I changed UMASK to 077 in /etc/login.defs and can confirm this doesn't have any effect. I guess because: +--- | # UMASK is the default umask value for pam_umask and is used by +---[ file:///etc/login.defs ] and +--- | $ rgrep umask /etc/pam.d || echo no | no +--- So all of this might not work either way unless someone manually enables pam_umask? Ansgar
Re: Seeking consensus for some changes in adduser
Ansgar writes: > On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote: >> > > > > >> Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 >> >> According to the history of that patch, we have some old consensus to >> move toward usergroups and a default umask of 0002 (except for root >> which gets 0022). > > On systems that don't use usergroups for all/some users, doesn't this > change make all files writable by other users by default? That would > seem like a very unsecure change on upgrades (or as a default). AFAIK systems that don't use usergroups are already not running in standard Debian configuration, since we default to USERGROUPS_ENAB being 'yes' in login.defs (and likewise USERGROUPS 'yes' in adduser.conf). If the sysadmin has chosen to change this, then a tighter umask is appropriate, but that's what they ought to get automatically reading this from login.defs: # If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value # for private user groups, i. e. the uid is the same as gid, and username is # the same as the primary group name: for these, the user permissions will be # used as group permissions, e. g. 022 will become 002. However, I suspect that something is a bit broken about this anyway, since I just tested and get a umask of 0022 when logging in via ssh to a system with USERGROUPS_ENAB 'yes'. The downside of having this set too tight is that it makes it harder to do the thing that usergroups is supposed to facilitate: Setting up directories that have shared group ownership, with the group s-bit set, such that all members of the group can have shared access to the directory. If the umask is too restrictive, then such shared directories give the appearance of working until someone tries to edit a file created by someone else, at which point they discover that its owned by the original user, and read-only for the shared group, which stops them editing it. I'd say that working out that this is due to the umask settings is a bit beyond most users. I seem to remember trying to work out where to fix this a few years ago, and discovering that we'd managed to break bits of the way it was meant to work, such that one ends up with a 0022 umask despite what it says in login.defs. Whatever we decide, we should try to make sure that there is a single place where the local admin can change the default and have it reflected in all the places that a umask might end up being set, be that in any of our Desktop environments, on the console, via ssh, and perhaps even as defaults for things like samba. We should also ensure that the conditional behaviour that's described in login.defs really happens, so that people can change away from usergroups and automatically get a safe umask setting to match. > (Though I think the current world-readable by default is already quite > bad. It seems like a unsafe choice on both single-user and multi-user > systems...) I agree -- cases such as ~/public_html not working well with such a umask are things that the user should notice and be easily able to discover how to fix, if they so wish. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 09:28:24 +, Simon McVittie wrote: >On Thu, 10 Mar 2022 at 06:37:58 +0100, Marc Haber wrote: >> Are we using ACLs [by] Default already in other places of the Debian >> system? > >For user-facing purposes I don't think so (although they're available to >anyone who wants to set them), I would rather not be the first one doing so. 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
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 at 06:37:58 +0100, Marc Haber wrote: > Are we using ACLs [by] Default already in other places of the Debian > system? For user-facing purposes I don't think so (although they're available to anyone who wants to set them), but they're how the udev/logind "uaccess" mechanism (the reason you don't need to be in the audio group any more) is implemented. (Briefly: devices that a physically-present user should be able to access, like audio, cameras, graphics acceleration and gamepads, are 0660 and owned by root:audio or similar, and tagged with "uaccess" by udev rules. When a user logs in or out, logind iterates through all devices attached to the relevant seat that have the uaccess tag, and does the equivalent of `setfacl -m user:$uid:rw-` on login or `setfacl -x user:$uid` on logout. On logout, it also tells the kernel to "revoke" existing file descriptors for device nodes where this is possible, notably input devices. The practical effect is that you can access these devices if and only if you are logged in, but you cannot ssh in and record another user unless you have extra privileges.) smcv
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 14:35:52 -0600, Richard Laager wrote: >If the admin can change the default DIR_MODE that applies to system user >home directories, then any postinst script doing `adduser --system` >needs to also explicitly chmod its home directory if it needs anything >more permissive than 700 or more restrictive than 755. This is true >today and remains true whether or not the default DIR_MODE is changed. Anything that NEEDS to be written in postinst scripts is bad. I'd rather implement a SYSTEM_DIR_MODE setting that applies to directories created during creation of a --system user. Would that help with the issue? >> How would chown handle the dot case intelligently? > >Something along the lines of see if the user exists. Michael Stone has elaborated on that topic and told us how chown already behaves. 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
Re: Seeking consensus for some changes in adduser
On Thu, 10 Mar 2022 00:04:38 +0100, Ansgar wrote: >On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: >> Those are actually unrelated--the big reason for the more permissive >> umask is to allow people to seamlessly work with other people in a >> group, especially within setgid shared directories. Those shared >> directories can be anywhere, and are likely *not* in a single user's >> home. > >Setting a default ACL on project directories seems a technical better >solution for this problem. It would only affect permissions of files >that should intentionally be group-readable, not all files created >anywhere. Are we using ACLs bei Default already in other places of the Debian system? 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
Re: Seeking consensus for some changes in adduser
On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote: > (2) > #774046 #520037 > Which special characters should we allow for account names? Please consider the leading character separately from the rest of the characters: - leading digits sometimes causes programs to parse a 'username' as an 'user id' instead; you can see some of this here: https://github.com/systemd/systemd/issues/6237 I know I've seen more instances of this over the years. - leading dash may cause the username to be treated as command line options in some programs. I've lost references to this happening. While you can argue these are bugs in the programs involved, they do happen in the wild. Thus, I'd like to suggest that the regex be more restrictive for the first character. Thanks signature.asc Description: PGP signature
Re: Seeking consensus for some changes in adduser
On Thu, Mar 10, 2022 at 12:04:38AM +0100, Ansgar wrote: On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: Those are actually unrelated--the big reason for the more permissive umask is to allow people to seamlessly work with other people in a group, especially within setgid shared directories. Those shared directories can be anywhere, and are likely *not* in a single user's home. Setting a default ACL on project directories seems a technical better solution for this problem. Not really--that requires ACL support, and ACL management tends to be a PITA for actual people. It would only affect permissions of files that should intentionally be group-readable, not all files created anywhere. With usergroups, group-readable is a no-op unless you've done something to change the group.
Re: Seeking consensus for some changes in adduser
On Wed, 2022-03-09 at 17:29 -0500, Michael Stone wrote: > Those are actually unrelated--the big reason for the more permissive > umask is to allow people to seamlessly work with other people in a > group, especially within setgid shared directories. Those shared > directories can be anywhere, and are likely *not* in a single user's > home. Setting a default ACL on project directories seems a technical better solution for this problem. It would only affect permissions of files that should intentionally be group-readable, not all files created anywhere. Ansgar
Re: Seeking consensus for some changes in adduser
On Tue, Mar 08, 2022 at 12:29:43PM -0700, Sam Hartman wrote:
I don't think it makes sense to move toward 0700 home directories and to
loosen the umask for usergroups.
Those are actually unrelated--the big reason for the more permissive
umask is to allow people to seamlessly work with other people in a
group, especially within setgid shared directories. Those shared
directories can be anywhere, and are likely *not* in a single user's
home.
On Wed, Mar 09, 2022 at 09:00:14PM +0100, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
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.
This was changed in coreutils to be posix-compliant more than 20 years
ago. The spec is that chown accepts user:group syntax, and chown will
always first attempt to split on ":". If there is no :, chown will try to
resolve the whole argument as a username (that is, regardless of whether
there's a "."). If the username isn't resolvable *and* it contains a
".", it will try to split on the first "." and use the left side as the
username and the right side as the group. So *only if* someone attempts
to use a dot-containing username in chown without a : and the
dot-containing username is invalid, then it might be interpreted as a
user.group spec. Now, if someone is trying to actually use user.group
syntax rather than the user:group syntax that's been standard for 20+
years, that will definitely break in the presence of dot-containing
usernames. Given how common such usernames are on other systems, I'd
expect the breakage to be minimal by now, and a bug in anything still
using that syntax. We could make coreutils print a deprecation warning,
but that's never really been useful in the past; probably better to just
error out any time a . is used for something other than a valid username
and drop the 20+ year old compatability code.
On Wed, Mar 09, 2022 at 02:35:52PM -0600, Richard Laager wrote:
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
I think this is much more fragile/less predictable than the current
behavior as the results will be dramatically different depending on the
exact combination of valid users & groups. Better to just make sure
you stick with the standard user:group representation.
Re: Seeking consensus for some changes in adduser
Considering many have replied, I'll stick to that one: Marc Haber wrote on 08/03/2022 at 17:49:04+0100: > (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)? How about --disabled-login => shell is set to /usr/sbin/nologin ? Cheers! -- PEB signature.asc Description: PGP signature
Re: Seeking consensus for some changes in adduser
On 3/9/22 14:00, Marc Haber wrote:
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager
wrote:
On 3/8/22 10:49, Marc Haber wrote:
(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.
Having thought about this some more:
If the admin can change the default DIR_MODE that applies to system user
home directories, then any postinst script doing `adduser --system`
needs to also explicitly chmod its home directory if it needs anything
more permissive than 700 or more restrictive than 755. This is true
today and remains true whether or not the default DIR_MODE is changed.
How would chown handle the dot case intelligently?
Something along the lines of see if the user exists.
If I was to take a stab at an implementation (Python-ish pseudocode
here; yes I know chown is C):
group = None
if ':' in arg:
(user, group) = arg.split(':')
elif '.' in arg:
# This could be:
# user.group
# us.er.group
# user.gr.oup
# us.er.gr.oup
# Or user and/or group could have multiple dots.
# Idea A) Exactly one dot can mean either user.group or us.er
arg_split = arg.split(',', 2)
if len(arg_split) == 3:
# There was more than one dot.
user = arg
else:
# Split on dot.
(user, group) = arg.split('.')
if not getent(user):
# Treat the whole thing as a username.
user = arg
group = None
# Idea B) Loop over each possible split and see if any work.
# Exercise for reader.
else:
user = arg
--
Richard
OpenPGP_signature
Description: OpenPGP digital signature
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 14:10:04 +0100, Harald Dunkel wrote: >On 2022-03-08 17:49:04, Marc Haber wrote: >> (1a) would it be necessary to handle --system accounts differently? I >> think yes. > >I think it would be helpful to define "system account" and "normal user". >Neither adduser(8) nor useradd(8) provide a sufficient definition, >especially wrt the existing network directory services (LDAP, AD, etc). In adduser, a --system (sic!) account is one that is created using the --system option. Basically, the biggest difference is that its UID is allocated from a different UID range, see policy 9.2.2. I just see that policy says "dynamically allocated system users and groups", while it refers to uid 1000-5 as "dynamically alllocated user accounts". So I am happy that my (and adduser's) notion of system and user accounts actually matches policy, but I agree that we need to be more explicit in adduser, probably referring to Policy in the adduser docs. >Is a "system user" supposed to be a local account, defined in /etc/passwd >only? That is not defined in policy, but it should. The current policy editing process is based on a proponent suggesting an exact wording with the policy editors just giving advice. Since I don't have a strong position in this regard, I'm out here. >Related question: How are naming collisions between local entries and >the entries in a network directory service supposed to be handled? >Something like > > passwd: files sss > >in /etc/nsswitch.conf is not helpful, if a postinst script fails to >create a local account due to the entry it has found in freeipa, for >example. Not to mention that such a service might fail at boot time, >if the directory service is not available (yet). That is beyond adduser's scope. We're (as the adduser team) usually weasel out of that topic by saying that a system refering to a directory service is run by skilled staff, and we expect those people to do their job. It's a small team, adduser has been in limbo for years, so we need to concentrate on the traps that a novice or unexperiences user might fall into while relying on skilled users to work around the issues that we haven't found the time to fix. 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
Re: Seeking consensus for some changes in adduser
On Tue, 8 Mar 2022 17:02:06 -0600, Richard Laager 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
Re: Seeking consensus for some changes in adduser
On Tue, 8 Mar 2022 19:06:57 -0500, Timothy M Butterworth wrote: >On Tue, Mar 8, 2022 at 6:18 PM Richard Laager wrote: >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. Adduser can already be configured to allow that via a documented interface. We're talking about the default here. The only point where an account might be created before that configuration possibility becomes available is the Installer. 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
Re: Seeking consensus for some changes in adduser
On Wed, 9 Mar 2022 00:12:25 +0200, Adrian Bunk wrote: >On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote: >>... >> (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. >>... > >There is a DD with the login 93sam, and this is already outside of >what systemd accepts.[1] ... as "User" option in system files. Not going to begin another systemd flame war today. Bugs like that look like they'll probably only relevant for accounts that services run under. >Non-ASCII characters in account names sound like a lot of breakage >and CVEs to me. Agreed, but people want that. 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
Re: Seeking consensus for some changes in adduser
On Tue, 08 Mar 2022 20:48:46 +0100, Ansgar wrote: >On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote: >> > > > > >> Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 >> >> According to the history of that patch, we have some old consensus to >> move toward usergroups and a default umask of 0002 (except for root >> which gets 0022). > >On systems that don't use usergroups for all/some users, doesn't this >change make all files writable by other users by default? That would >seem like a very unsecure change on upgrades (or as a default). Maybe we need to adapt that patch to only set umask to 002 if the user's primary group is identically named. >(Though I think the current world-readable by default is already quite >bad. It seems like a unsafe choice on both single-user and multi-user >systems...) It surely references an administration style that sadly does not fit these days. 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
Re: Seeking consensus for some changes in adduser
On Tue, 08 Mar 2022 12:29:43 -0700, Sam Hartman wrote: >Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 As far as I understand, that's a PR against pam setting umask.to 002 on login, 022 for root. Especially the bug reports referenced there bring me directly and deeply into Debian-Ubuntu politics which is a significant drain for me. >According to the history of that patch, we have some old consensus to >move toward usergroups and a default umask of 0002 (except for root >which gets 0022). > >I was trusting the analysis in that merge request and assuming we >actually did have such a consensus. I am not aware of that. If we have consensus, then all the better. >But I'd ask you to look into the history of usergroups in Debian as part >of your decision process. Where would I read up on that? I am not deeply enough in those political things to be able to judge whether a discussion from 15 years ago is still valid today. 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
Re: Seeking consensus for some changes in adduser
On Wed, 09 Mar 2022 at 14:10:04 +0100, Harald Dunkel wrote: > I think it would be helpful to define "system account" and "normal user". > Neither adduser(8) nor useradd(8) provide a sufficient definition, > especially wrt the existing network directory services (LDAP, AD, etc). > Is a "system user" supposed to be a local account, defined in /etc/passwd > only? I think the intention is: - a system account is a uid used internally by system services (some common examples: www-data, messagebus, Debian-exim, _apt) - a normal user is either an account representing a person (like the 'smcv' user on Debian infrastructure), or a "role" account shared by several people but otherwise used in the same way as an account representing a person (like the "release" user on Debian infrastructure, which is used by the release team) That definition doesn't say anything about whether a system user is defined locally or in a directory service, but there are serious practical problems with managing system users via directory services, so system users should usually (always?) be defined locally. Normal users can either be local or in a directory service. In particular, if an early-boot service (like systemd or udev) or a service that might be required before networking comes up (like dbus-daemon) needs to know about a system user, then the system user must be defined locally, to avoid sequencing problems during boot. > Related question: How are naming collisions between local entries and > the entries in a network directory service supposed to be handled? Debian Policy now encourages new system accounts to be created with an underscore prefix (like _apt and _flatpak), so that they will not collide with human users' login names. This convention was borrowed from one of the BSDs, as a pragmatic way to reserve a namespace while keeping account names short. System accounts that existed before that Policy change have a bewildering variety of naming conventions, and renaming a pre-existing account is not straightforward, so older system account naming conventions like Debian-exim, systemd-coredump, debian-tor and messagebus (dbus-daemon) will unfortunately continue to exist for a long time. smcv
Re: Seeking consensus for some changes in adduser
On 2022-03-08 17:49:04, Marc Haber wrote: (1a) would it be necessary to handle --system accounts differently? I think yes. I think it would be helpful to define "system account" and "normal user". Neither adduser(8) nor useradd(8) provide a sufficient definition, especially wrt the existing network directory services (LDAP, AD, etc). Is a "system user" supposed to be a local account, defined in /etc/passwd only? Related question: How are naming collisions between local entries and the entries in a network directory service supposed to be handled? Something like passwd: files sss in /etc/nsswitch.conf is not helpful, if a postinst script fails to create a local account due to the entry it has found in freeipa, for example. Not to mention that such a service might fail at boot time, if the directory service is not available (yet). Regards Harri
Re: Seeking consensus for some changes in adduser
On Tue, Mar 8, 2022 at 6:18 PM Richard Laager 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. >
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
Re: Seeking consensus for some changes in adduser
On Tue, Mar 08, 2022 at 05:49:04PM +0100, Marc Haber wrote: >... > (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. >... There is a DD with the login 93sam, and this is already outside of what systemd accepts.[1] Non-ASCII characters in account names sound like a lot of breakage and CVEs to me. > Greetings > Marc cu Adrian [1] https://github.com/systemd/systemd/issues/6237
Re: Seeking consensus for some changes in adduser
I support the 0700 on home directories. On March 8, 2022, at 2:30 PM, Sam Hartman wrote: > "Marc" == Marc Haber writes: Marc> Hi, you might have noticed that the adduser package has gained Marc> I have some issues that I would like to solicit the opinion of Marc> my fellow DDs and to reach rough consensus about some changes Marc> that have been requested from Adduser in the BTS but I am Marc> reluctant to go through with on my own decision. Marc> (1) #202943, #202944, #398793, #442627, #782001 The bug Marc> reporters are requesting the default for DIR_MODE to be Marc> changed from 0755 to 0700, making home directories readable Marc> for the user only. Policy 10.9 states that directories should Marc> be 0755, but the policy editors probably didn't have user home Marc> directories in mind when they wrote that. Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 According to the history of that patch, we have some old consensus to move toward usergroups and a default umask of 0002 (except for root which gets 0022). I was trusting the analysis in that merge request and assuming we actually did have such a consensus. I don't think it makes sense to move toward 0700 home directories and to loosen the umask for usergroups. I'm fine with either direction, and would probably prefer the 0700 approach myself. But I'd ask you to look into the history of usergroups in Debian as part of your decision process.
Re: Seeking consensus for some changes in adduser
On Tue, 2022-03-08 at 12:29 -0700, Sam Hartman wrote: > > > > > > Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 > > According to the history of that patch, we have some old consensus to > move toward usergroups and a default umask of 0002 (except for root > which gets 0022). On systems that don't use usergroups for all/some users, doesn't this change make all files writable by other users by default? That would seem like a very unsecure change on upgrades (or as a default). (Though I think the current world-readable by default is already quite bad. It seems like a unsafe choice on both single-user and multi-user systems...) Ansgar
Re: Seeking consensus for some changes in adduser
> "Marc" == Marc Haber writes: Marc> Hi, you might have noticed that the adduser package has gained Marc> I have some issues that I would like to solicit the opinion of Marc> my fellow DDs and to reach rough consensus about some changes Marc> that have been requested from Adduser in the BTS but I am Marc> reluctant to go through with on my own decision. Marc> (1) #202943, #202944, #398793, #442627, #782001 The bug Marc> reporters are requesting the default for DIR_MODE to be Marc> changed from 0755 to 0700, making home directories readable Marc> for the user only. Policy 10.9 states that directories should Marc> be 0755, but the policy editors probably didn't have user home Marc> directories in mind when they wrote that. Take a look at https://salsa.debian.org/vorlon/pam/-/merge_requests/3 According to the history of that patch, we have some old consensus to move toward usergroups and a default umask of 0002 (except for root which gets 0022). I was trusting the analysis in that merge request and assuming we actually did have such a consensus. I don't think it makes sense to move toward 0700 home directories and to loosen the umask for usergroups. I'm fine with either direction, and would probably prefer the 0700 approach myself. But I'd ask you to look into the history of usergroups in Debian as part of your decision process.
Seeking consensus for some changes in adduser
Hi, you might have noticed that the adduser package has gained some momentum in the last week, thanks to a new volunteer helper, Jason Franklin, who has taken care of the actual code. I am acting as advisor and Debian specialist in this team and am currently doing bug triage. For the people who don't know about the program, adduser is kind of a wrapper around useradd that is used in Debian to create local accounts. While it of course can also create "normal" user account, it has evolved in the last 20 years to kind of a policy layer that can be used from maintainer scripts to create package-related accounts, following Debian policy and avoiding bugs. adduser's defaults need careful choosing since there is a lot of breakage potential. I have some issues that I would like to solicit the opinion of my fellow DDs and to reach rough consensus about some changes that have been requested from Adduser in the BTS but I am reluctant to go through with on my own decision. (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). (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. (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)? (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"? (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? Thanks for helping adduser being a better package! 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
