Repository navigation
subid ranges sourced from the network store #154
Description
We are seeing a lot of excitement on the podman front running containers as not root.
We are taking advantage of User Namespace and specifically shadow-utils with /etc/subuid, /etc/subgid nad newuidmap and newgidmap.
But we are now being contacted by "enterprise" customers who use large databases of users and they want these files and UIDMap information to be handled via ldap or FreeIPA.
Has there been any thought into making this info available via nsswitch?
Reacted by Tri Nguyen, Jens Dieskau, Daniel Schier, Anthony Rabbito, Eric Engstrom, Yuuta Liang, Brodi, Harmen Stoppels, Mattias Fransson, Alexey Nekrasov and 1 more
Activity
giuseppe commentedon Feb 15, 2019
I think there should be a way where we split the 32 bits uid/gid, so that a UID gets the additional UIDs/GIDs where the high 16 bits are equal the the UID itself.
i.e.
user 1000 -> 65536000-65601535,
user 1001 -> 65601536-65667071,
vapier commentedon Feb 15, 2019
shadow shouldn't enforce any such policy decision like that when it comes to id space segmentation. it can make best practice recommendations, but that's it.
i'm not sure we can utilize nsswitch w/out coordinating with glibc. but if glibc did add support for new keywords (like "subuid" and "subgid"), then that seems like a design that would work.
codonell commentedon Feb 19, 2019
The broader question is one about APIs. The existing glibc APIs that manage UIDs/GIDs trigger the NSS infrastructure to load and parse /etc/nsswitch.conf, this in turn loads plugins to respond to service requests in an authoritative fashion e.g. LDAP NSS module. There are no APIs that deal with subuid, subgid, or the concept of newuidmap and newgidmap setup for the guest namespace.
The existing infrastructure would require changes like this:
Is that what everyone is thinking about?
rhatdan commentedon Feb 20, 2019
Yes this is exactly what I was thinking.
codonell commentedon Feb 20, 2019
I should note that when I said "new API for managing" I meant only that we provide functions that allow you to query the existing data, but not modify that data. We don't need dyanmic assignment to be baked into glibc, that has deeper policy implications, and shadow-utils and admins can do that themselves. Likewise the LDAP admin can setup the ranges as they wish without any need to have an API that does the assignment.
lukasheinrich commentedon Feb 22, 2019
this is very interesting to academic environments as well, which use RH-based distros (CERN Scientific Linux 6 / CERN Centos 7) and have shared clusters to which users can login
brauner commentedon Feb 22, 2019
I have been talking about something like this with @poettering just a short while ago. On the @lxc side we allow for isolated idmaps, i.e. we have a way to give each container an idmap that is isolated from all other containers. For LXD it's easy to keep track what maps it has given away and how many it has left but it obviously becomes a problem when another container manager is using the same map. Having a central registry where we can - in a race free manner - record something along the lines of:
would be quite helpful.
I actually think we'd want something even better such that we can query:
brauner commentedon Feb 22, 2019
This should see input from all active people who co-maintain @shadow-maint with @hallyn and myself. Would also good to hear what @stgraber thinks.
rhatdan commentedon Feb 22, 2019
Lets not confuse two different things though.
We have the UID's allocated to users to for their user namespace. Then we have UID Ranges allocated for root running services that want to use User Namespace for separation.
This Issue is more about the UID's allocated for Users.
brauner commentedon Feb 22, 2019
The two are conceptually identical only their permissions differ. If you use new{g,u}idmap for both user and root services than sub{g,i}id decides what you are allowed to map independent of whether you're root or not
rhatdan commentedon Feb 22, 2019
Well I am not suggesting we use newuidmap for both. No reason to use this for a root running container engine.
brauner commentedon Feb 22, 2019
We should have a central way for all container engines to register their id allocations. If it works for unpriv users it works for root as well so there's no additional work associated with this.
poettering commentedon Feb 22, 2019
I must say I am not particularly convinced that /etc/subuid and /etc/subgid is such a great idea in the first place. Storing these registrations in /etc as if they were system configuration sounds wrong to me, we shouldn't do that anymore. Unless something is being reconfigured /etc should really be considered read-only, and range registration in /etc is something diametrically opposed to that, as it stores runtime information among the configuration in /etc.
In systemd we allocate user IDs dynamically at various places, including in nspawn's userns support and for DynamicUser=1 support for system services. But we never ever write this to /etc, as that's really not suitable for dynamically changing registrations. However, we do supply glibc NSS modules that make sure that whatever we register (regardless if individual uids or ranges of uids) shows up in the system's user database. And I think that's a general approach to follow when allocating user ranges: use NSS as registration database: make sure that the user and all other apps see that you own a range by making sure your users show up in NSS. This reuses existing concepts for maintaining registered ranges (as libc getpwuid() and getpwnam() will just report our entries), and is also friendly towards users, as for example "ps" will show all processes of a userns-using container as owned by your package. It also makes sure that classic user mgmt tools such as "adduser" automatically respect your uid range registrations, since they already check NSS before picking a UID anyway.
hence, from the systemd PoV: I am very sure we'll never begin using /etc/subuid and /etc/subgid, I think at this time we really shouldn't add any more static databases in /etc that need to be dynamically managed. Instead, we just pick a UID we consider suitable, check against NSS, and only use it if its not listed there yet (if it is, we pick a different UID). At the same time we make the UID we now took possession show up in NSS so that everybody else knows.
Or in other words: instead of trying to get everybody on board with sharing a new set of database files in /etc/, and then extending it for the network, just make everybody use the same (already existing) API instead (i.e. glibc NSS), and leave it up to the packages to register their ranges with it. Standardize on existing APIs rather than new files. The packages can then decide on their own how they manage their assignments and replicate them across the network.
(In case you wonder: yes, it's very easy to write an NSS module that returns for a UID x from some range a fixed user name "foobar-x", and vice versa)
rhatdan commentedon Feb 22, 2019
Well that is exactly what this issue is about. Adding NSS support to newuidmap and newgidmap.
brauner commentedon Feb 22, 2019
I think you misunderstand these files. No one intends to use them as databases and they aren't used as such now. They are config files that statically tell you what ids a user can use.
154 remaining items
rhatdan commentedon Jul 11, 2021
@hallyn any idea when you will release a new version of shadow-utils, with this feature?
hallyn commentedon Jul 13, 2021
I've been meaning to do that for awhile...
I'll plan on doing a release tomorrow afternoon (central time).
rhatdan commentedon Jul 20, 2021
@hallyn Still waiting...
hallyn commentedon Jul 22, 2021
rhatdan commentedon Jul 22, 2021
Thanks
Basics of 'subid ranges' support for IPA provider.
Basics of 'subid ranges' support for IPA provider.
Support subordinate user and group ID ranges on enterprise set-ups
.github/workflows: Remove golangci-lint
.github/workflows: Remove golangci-lint
.github/workflows: Run the tests on Ubuntu 22.04
.github/workflows: Run the CI on Ubuntu 22.04
.github/workflows: Run the CI on Ubuntu 22.04
.github/workflows: Run the CI on Ubuntu 22.04
.github/workflows: Run the CI on Ubuntu 22.04