+++ This bug was initially created as a clone of Bug #1715193 +++ Lots of people are playing with the new container runtime tools that run containers as non root, like Podman and Buildah. These tools take advantage of the /etc/subuid and /etc/subgid files provided by shadow-utils and updated via useradd for managing extra uids to be used by the user within containers. A lot of people using these tools want to be able to destribute the content in these files the same way they do for content in /etc/passwd. Basically they want to have nsswitch support for them.
https://github.com/shadow-maint/shadow/issues/154
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
Created attachment 1626793 [details] Proposal for adding subuid and subgid to nsswitch
(In reply to Daniel Walsh from comment #5) > Created attachment 1626793 [details] > Proposal for adding subuid and subgid to nsswitch This is a good start. The proposal needs to take into account the feedback from upstream, integrate that and point out why the current direction is still the best. The upstream feedback can be extracted from here: https://github.com/shadow-maint/shadow/issues/154 I'd like to see the proposal discuss the issues of UID/GID space exhaustion. Even if it's just to say that's a problem that each site has to tackle. Likewise a discussion about dynamic vs. static allocation is a must.
Hi, FYI, in Amadeus we wish to use at some point podman on Linux servers shared among Amadeus developers. The fact that machines are shared also implies that users are managed by a remote server, in our case Active Directory (using LDAP protocol). So indeed for us having these files /etc/subuid and /etc/subgid as the only mean to configure multi-user containers is currently one blocker for our adoption of podman, as deploying these static files on all machines each time an Amadeus developer enter or leaves the company is not convenient. I have read the discussion in https://github.com/shadow-maint/shadow/issues/154, to be honest I miss too many concepts to understand it correctly. As much as possible for a rapid adoption of podman, the final solution shall be easy to configure and deploy. Let's say in addition to fixed uid/gid which exists today already in Active Directory, podman also needs ranges of uid/gid to be statically allocated in Active Directory, then we would need to wait that: - Microsoft supports that (since I don't know anything to Active Directory, maybe it's needed, maybe not) - Our sysadmin do setup that range allocation correctly. Maybe I misunderstood what Lennart Poettering wrote in https://github.com/shadow-maint/shadow/issues/154 but if indeed we could make podman run without the need of statically allocated id ranges, that would mean for us no change at all on Active Directory side, which is simpler for deployment for us. If indeed ranges could be dynamically allocated by a local service on the machine without needing to same that user X can user range Y in any config file anywhere, it looks more appealing. Anyway, our primary need is to be able to run containers containing more than a single user, rootless, where the host user running podman is defined in an Active Directory database. I would be glad to test any future implementation in podman/glibc allowing to do this ;) Cheers, Romain
(In reply to Romain Geissler from comment #7) > Hi, > > FYI, in Amadeus we wish to use at some point podman on Linux servers shared > among Amadeus developers. The fact that machines are shared also implies > that users are managed by a remote server, in our case Active Directory > (using LDAP protocol). So indeed for us having these files /etc/subuid and > /etc/subgid as the only mean to configure multi-user containers is currently > one blocker for our adoption of podman, as deploying these static files on > all machines each time an Amadeus developer enter or leaves the company is > not convenient. Thank you for sharing your perspective. This is very helpful. > I have read the discussion in > https://github.com/shadow-maint/shadow/issues/154, to be honest I miss too > many concepts to understand it correctly. As much as possible for a rapid > adoption of podman, the final solution shall be easy to configure and > deploy. Let's say in addition to fixed uid/gid which exists today already in > Active Directory, podman also needs ranges of uid/gid to be statically > allocated in Active Directory, then we would need to wait that: > - Microsoft supports that (since I don't know anything to Active Directory, > maybe it's needed, maybe not) > - Our sysadmin do setup that range allocation correctly. I think you can add new data structures to Active Directory. I have no idea how common an activity this is, but it's certainly a (one-time) task that has to happen, in addition to the day-to-day data management. The other concern I would expect that auditors might prefer if every user had just a single POSIX UID/GID combination. > Maybe I misunderstood what Lennart Poettering wrote in > https://github.com/shadow-maint/shadow/issues/154 but if indeed we could > make podman run without the need of statically allocated id ranges, that > would mean for us no change at all on Active Directory side, which is > simpler for deployment for us. If indeed ranges could be dynamically > allocated by a local service on the machine without needing to same that > user X can user range Y in any config file anywhere, it looks more appealing. I think you can play with the dynamic assignment today, using systemd-nspawn: <https://systemd.io/UIDS-GIDS.html#special-systemd-uid-ranges> <https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#--private-users=> The downside of course is that these IDs aren't unique over time. I don't know if podman can use these dynamic ranges today, and if using these features is still considered “rootless”.
Podman is relying on newuidmap and newgidmap for a rootless user to run containers. At least this is the use case we are after. We are not currently looking at the use case where a root running podman is attempting to use ranges of UIDs for each different container, so that they run in different User Namespaces.
> The downside of course is that these IDs aren't unique over time. If allocated IDs were dynamic, would it be possible that I run a container on a given machine, bind mount a local filesystem directory, write a secret into a file in there with a user which is not the default user of the container (so that I am allocated a dynamic id), then stop the container, and the file remains on the filesystem, using this "fake" id, unrelated to my linux user ? And then another unrelated developer could run another unrelated container, be allocated the same recycled "fake" user id, and thus read my secret file ? If yes indeed, statically allocated ranges seems more secure.
I think the answer to this is clearly yes. This issue always exists with the reuse of UIDs.
I've commented on this upstream again, summarizing the past comments and adding my own reflection on the design direction: https://github.com/shadow-maint/shadow/issues/154#issuecomment-571415244 Next week I'm going to close this issue as CLOSED/UPSTREAM, as something we can track upstream. Fedora would inherit a choice made and designed upstream.