FS#68741 - [filesystem][shadow] include and backup /etc/sub{uid,gid}
Attached to Project:
Arch Linux
Opened by David Runge (dvzrv) - Wednesday, 25 November 2020, 16:10 GMT
Last edited by David Runge (dvzrv) - Wednesday, 19 October 2022, 22:15 GMT
Opened by David Runge (dvzrv) - Wednesday, 25 November 2020, 16:10 GMT
Last edited by David Runge (dvzrv) - Wednesday, 19 October 2022, 22:15 GMT
|
Details
Description: The usermod options to create subordinate uids
and gids (-v/--add-subuids and -w/-add-subgids,
respectively) rely on the files /etc/subuid and /etc/subgid
to be present, else the usermod errors out with:
``` usermod: /etc/subuid does not exist, you cannot use the flags -v or -V ``` The files should be created (empty) as part of the shadow package and be tracked in the backup array to not be overwritten. Other distributions even go as far as to auto-create subuids and subgids for newly created users (to my knowledge this is the case for e.g. fedora), which can be quite useful. However, I don't know how exactly that is achieved (probably the shadow package can be configured to set defaults for user-creation for this). Additional info: * package version: 4.8.1 * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: E.g. trying to configure podman [1] if no subuids/subgids have been configured manually yet: usermod --add-subuids 165536-169631 --add-subgids 165536-169631 <user> [1] https://wiki.archlinux.org/index.php/Podman#Configuration |
This task depends upon
Closed by David Runge (dvzrv)
Wednesday, 19 October 2022, 22:15 GMT
Reason for closing: Implemented
Additional comments about closing: Implemented with filesystem 2022.10.18-1 and shadow 4.11.1-3
Wednesday, 19 October 2022, 22:15 GMT
Reason for closing: Implemented
Additional comments about closing: Implemented with filesystem 2022.10.18-1 and shadow 4.11.1-3
FS#69933for easier configuration and opting out ofsubuid/subgid creation for new users?
Why would there need to be a hook related to user creation?
@nl6720: I guess that would make a lot of sense! At first I thought, that providing the file there would be an anti-pattern since its man page is provided by shadow, but that's also the case for the shadow man page... so.
FS#69933you might also want to look at what Fedora does as with over 30 unsupported variables to annotate/remove the diff against upstream is larger than the file itself.Edit:
Fedora has 33 variables as unsupported while I have 32 due to how to classify MOTD_FILE, technically it is functional just should not be used as its functionality is duplicated by pam_motd and using it the motd will be printed twice.
[1] https://src.fedoraproject.org/rpms/shadow-utils/blob/rawhide/f/shadow-utils.login.defs
I'm not sure whether I would want to go back to providing a custom login.defs. The past has shown that it is problematic to track the changes that way, unless the package maintainer is very aware.
Adding notes as to which of the options are not supported would be really great for the users though.
My current feeling is that we should move them to the shadow package.
I'm fine to add /etc/sub{u,g}id to the filesystem for consistency, and we can evaluate later the move to shadow.
Disabling the feature via file removal would involve deleting the files themselves then overriding /usr/lib/tmpfiles.d/arch.conf.
Is the expected method to disable the feature to set SUB_GID_COUNT and SUB_UID_COUNT to 0 in login.defs or is the feature expected to always be enabled?
Hm, do new users get overlapping UID/GID ranges applied there? If yes, then we at least need to add a message to the .install file.
I'm not sure how easy it would be to script a cleanup of these ranges on existing systems.
# useradd -m testuser1
# useradd -m testuser2
# useradd -m testuser3
I got:
==> /etc/subuid <==
testuser1:100000:65536
testuser2:165536:65536
# See subuid(5) for details.
# The configuration for subordinate user ids.
testuser3:231072:65536
==> /etc/subgid <==
testuser1:100000:65536
testuser2:165536:65536
# See subgid(5) for details.
# The configuration for subordinate group ids.
testuser3:231072:65536
Nothing overlaps, though the non-round numbers are not pretty.
The comments may need to be removed, since they get moved around.
@seblu: Sorry for suggesting the comments (in a perfect world they would be a great suggestion)... Guess they need to be removed again.
Afterwards we could deal with https://bugs.archlinux.org/task/33677 (the changes for that are already added to shadow).
Edit:
/etc/tmpfiles.d even leaving /usr/lib alone.
```
testuser2:100000:65536
testuser1:165536:131068
testuser3:296604:65536
```
The distance is calculated properly and all should be fine.
@loqs: Why would users want to prevent the creation of the subuids/subgids though?
If the tmpfiles.d file is masked, the creation of other files is also prevented (e.g. /etc/crypttab, /etc/fstab, etc.)
As far as I am aware all files currently shipped in /usr/share/factory by the filesystem package are also shipped in /etc/.
With generating subuid/subgid per user by default, we can run rootless containers [1] without further configuration (if user namespaces are enabled).
The login.defs options are also defaults upstream, so from a packaging and distribution perspective this makes a lot of sense (in regards to being pragmatic).
[1] https://wiki.archlinux.org/title/Podman#Rootless_Podman
FS#63648).The gaping security hole of user namespaces is also mentioned in https://wiki.archlinux.org/title/Security#Sandboxing_applications .
I asked in [1] what the expected / supported methods of disabling the feature was or if it is expected to always be enabled and received no response prior to posting [2].
If /etc/subgid, /etc/subuid, /usr/share/factory/sudgid and /usr/share/factory/subuid are moved to shadow along with a new tmpfiles.d snippet that would avoid disabling filesystem's tmpfiles.d snippet when using that approach.
Edit:
With respect to why disable subuid and sugid creation when the kernel can block none root user namespace use can be seen as defense in depth or documenting through the configuration that such use is not expected / supported on this particular system.
[1] https://bugs.archlinux.org/task/68741#comment212021
[2] https://bugs.archlinux.org/task/68741#comment212037
If we do move the files in the future, it will indeed get much easier to disable this functionality.
FS#76240to track the moving of files.@loqs: I don't like files in /etc/ being recreated after a purposeful user deletion. That's questioning the very interest to use tmpfiles as it is now in filesystem. But I don't remember the use case (containers with empty /etc?).
https://wiki.archlinux.org/title/Linux_Containers#Enable_support_to_run_unprivileged_containers_%28optional%29 shows an example with the root user. If that's desirable, then perhaps the default /etc/subuid and /etc/subgid should include those lines.
Edit:
Looks like root subuids are a thing: https://á.se/unprivileged-containers-as-root-oxymoron/ .
> If that's desirable, then perhaps the default /etc/subuid and /etc/subgid should include those lines.
I'm not sure whether that is desirable or not. How do other distributions deal with it?
The same can be said about regular non-root users, and yet useradd will create subuid and subgid entries for them by default :)
A reason for this change is to make podman work by default, so a question could be asked, why not fix it for lxc too at the same time?
Looking at this long standing upstream ticket [1] and the accompanying pull request [2], it seems that the days of /etc/sub{g,u}id might be numbered, as an NSS plugin has been integrated with shadow.
Some work seems also to take place in systemd [3] towards working on generating sub{g,u}id ranges for users. (thanks to Kristian for going link hunting)
Therefore I believe it is not worth the hassle to add root in /etc/sub{g,u}id by default, as it is a rather niche setup and users can add root manually if they want to.
If we'd add root (e.g. with the first available range) it would overlap with any manual user setup from before this change, requiring users to manually shift ranges around etc.
[1] https://github.com/shadow-maint/shadow/issues/154
[2] https://github.com/shadow-maint/shadow/pull/321
[3] https://github.com/systemd/systemd/issues/13717