While the systemd project encourages the use of systemd-nsresourced for
creating uids and gids for containers,
many users also rely on the sub{u,g}id system (new{u,g}idmap, getsubids,
/etc/sub{u,g}id).
This is important for more than just container managers: to delete a file in a
user's home directory,
one might need to enter into a user namespace to have the proper permissions
(ex. via `podman unshare`).
This is also true with the foreign uid system that systemd introduced, where a
user may need to enter
into a user namespace to delete files owned by the foreign uid range in their
current directory.
For reference, that looks something like:
$ unshare --user /bin/sh
sh$ varlinkctl call --push-fd /proc/self/ns/user \
/run/systemd/io.systemd.NamespaceResource \
io.systemd.NamespaceResource.AllocateUserRange \
'{"name":"ns-1234","size":1,"target":0,"userNamespaceFileDescriptor":0,"type":"self","mapForeign":true}'
sh$ rm -rf ./dir-owned-by-foreign-ids
The issue is that, right now, it is impossible to do both at the same time:
enter into an unprivileged
user namespace with all of shadow-utils's subuids and subgids mapped (like
podman unshare does) *and*
also map the foreign uid range. The /proc/$pid/uid_map file can only be written
to once, so a single
privileged service must understand both subids and foreign ids at the same time.
This doesn't necessarily require any changes to systemd, as this is something
that should be supported by
shadow-utils (I have an open issue:
https://github.com/shadow-maint/shadow/issues/1729).
I'm posting here to request a systemd expert to weigh in on my proposal and
tell me if my understanding
of foreign id ranges is correct and that what I'm proposing is a solution (see
the linked issue for details).
I'd hate to add a feature to shadow-utils that turns out to be a security issue
when used alongside
systemd-nsresourced!
Thanks!
Skye
