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
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
David Runge (dvzrv)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

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
Comment by Giancarlo Razzolini (grazzolini) - Thursday, 26 November 2020, 11:24 GMT
Is this something that we could report upstream?
Comment by Sven-Hendrik Haase (Svenstaro) - Friday, 22 July 2022, 03:55 GMT
I think following Fedora here would be quite nice for users that want to use podman out of the box. However, it might be good to have this done upstream. I wonder which upstream would even be responsible for this in particular.
Comment by nl6720 (nl6720) - Wednesday, 27 July 2022, 07:29 GMT
Wouldn't it make more sense to place them in the filesystem package, since that's where /etc/passwd, /etc/group and similar files are packaged?
Comment by Sven-Hendrik Haase (Svenstaro) - Monday, 29 August 2022, 00:51 GMT
Adding seblu. seblu, what do you think about this suggestion by nl6720? I think it would make sense and it would make tools such as podman just work without prior configuration. However, we'd still need to figure out the hook when creating users.
Comment by loqs (loqs) - Monday, 29 August 2022, 01:54 GMT
Could the /etc/login.defs be updated with the defaults for SUB_UID_MIN SUB_UID_MAX SUB_UID_COUNT SUB_GID_MIN SUB_GID_MAX SUB_GID_COUNT before or at the same time this is implemented  FS#69933  for easier configuration and opting out of
subuid/subgid creation for new users?

Why would there need to be a hook related to user creation?
Comment by David Runge (dvzrv) - Sunday, 16 October 2022, 16:53 GMT
@loqs: Thanks, I'll look into the /etc/login.defs config (likely dropping our specific one in favor of patching upstream).

@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.
Comment by loqs (loqs) - Sunday, 16 October 2022, 17:56 GMT
@dvrv I have provided you with an updated diff in  FS#69933  you 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
Comment by David Runge (dvzrv) - Sunday, 16 October 2022, 19:12 GMT
@loqs: Thanks!

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.
Comment by Sébastien Luttringer (seblu) - Monday, 17 October 2022, 18:00 GMT
I'm trying to figure out if there are still reasons to have the /etc/{passwd,shadow,group} to belong to the filesystem package.
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.
Comment by David Runge (dvzrv) - Monday, 17 October 2022, 20:21 GMT
@seblu: I don't know whether there are any considerations besides "historical reasons", but we also have e.g. /etc/securetty in it, which is used by shadow (the package) as well.
Comment by Sébastien Luttringer (seblu) - Monday, 17 October 2022, 23:23 GMT
ok, let's go ahead and add the sub{ug}id files into filesystem.
Comment by loqs (loqs) - Tuesday, 18 October 2022, 01:19 GMT
Deleting /etc/subgid and /etc/subuid and the files are recreated by tmpfiles from their copies in /usr/share/factory.
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?
Comment by nl6720 (nl6720) - Tuesday, 18 October 2022, 09:10 GMT
With shadow 4.11.1-2, /etc/subuid and /etc/subgid get populated for newly created accounts, but what about existing ones? Should there be an .install script that iterates over existing users and updates /etc/subuid and /etc/subgid?
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 09:21 GMT
@nl6720: Thanks for testing!

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.
Comment by nl6720 (nl6720) - Tuesday, 18 October 2022, 09:33 GMT
Running:

# 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.
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 09:44 GMT
@nl6720: Thanks! I was referring to users setup in /etc/sub{g,u}id before the update vs. adding further after the update (sorry, I should have been more clear on that).

@seblu: Sorry for suggesting the comments (in a perfect world they would be a great suggestion)... Guess they need to be removed again.
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 10:00 GMT
@seblu if you remove the comments and release a pkgrel bump to testing, we can release filesystem and shadow together as soon as filesystem is signed off (shadow already has enough signoffs).
Afterwards we could deal with https://bugs.archlinux.org/task/33677 (the changes for that are already added to shadow).
Comment by loqs (loqs) - Tuesday, 18 October 2022, 11:27 GMT
Noextract /etc/subgid /etc/subuid and symlinking /etc/tmpfiles.d/arch.conf to /dev/null to prevent their creation with tmpfiles.d seems to work as expected.
Edit:
/etc/tmpfiles.d even leaving /usr/lib alone.
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 12:13 GMT
Just tested with an existing user pre-update and adding two more after upgrading:

```
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.)
Comment by loqs (loqs) - Tuesday, 18 October 2022, 12:19 GMT
@dvrv without a use case for the feature why enable it and increase the system's attack surface?
As far as I am aware all files currently shipped in /usr/share/factory by the filesystem package are also shipped in /etc/.
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 12:29 GMT
Hm, if people are concerned about attack surface, they should be running e.g. linux-hardened, where user namespaces are off by default or switch off user namespaces.

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
Comment by nl6720 (nl6720) - Tuesday, 18 October 2022, 12:32 GMT
linux-hardened is not suitable for all use cases, e.g. hibernation doesn't work (  FS#63648  ).

The gaping security hole of user namespaces is also mentioned in https://wiki.archlinux.org/title/Security#Sandboxing_applications .
Comment by loqs (loqs) - Tuesday, 18 October 2022, 15:34 GMT
@dvrz I am not suggesting the defaults are inappropriate or that rootless podman should not be supported by default, I am suggesting I have no use case for subgid / subuid so I was exploring ways to disabled it.
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
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 16:40 GMT
@loqs: I see. I remember you asking it, but couldn't find the reference (too many open tickets right now).

If we do move the files in the future, it will indeed get much easier to disable this functionality.
Comment by David Runge (dvzrv) - Tuesday, 18 October 2022, 21:37 GMT
I've created  FS#76240  to track the moving of files.
Comment by Sébastien Luttringer (seblu) - Tuesday, 18 October 2022, 23:55 GMT
@dvrz: I pushed a new version without the comments. You can move both packages when you are ready.

@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?).
Comment by loqs (loqs) - Wednesday, 19 October 2022, 01:38 GMT
@seblu I think the use case of empty /etc is explained in https://0pointer.net/blog/projects/stateless.html
Comment by nl6720 (nl6720) - Wednesday, 19 October 2022, 11:33 GMT
Does the root account need subuids and subgids?

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/ .
Comment by David Runge (dvzrv) - Wednesday, 19 October 2022, 14:10 GMT
@nl6720: Hm... not sure. If people want root to have subuid/subgid entries, then they can still add that manually I guess.

> 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?
Comment by nl6720 (nl6720) - Wednesday, 19 October 2022, 14:40 GMT
> If people want root to have subuid/subgid entries, then they can still add that manually I guess.

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?

Comment by David Runge (dvzrv) - Wednesday, 19 October 2022, 20:30 GMT
After a lot of discussion on IRC with some members of staff we came to the conclusion that it is likely not really worth adding root by default.

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

Loading...