-
Notifications
You must be signed in to change notification settings - Fork 541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] allow to skip setgroups(2)
#1020
Comments
setgroups(2)
setgroups(2)
If we do add an option, it needs to have a really scary name ( In my view, the best solution to the problem of such volumes is to do exactly what LXD does -- "punch out" the GID that the storage volume is owned by (by adding a single 1:1 mapping for that GID). The most ideal solution would be the next-gen "shiftfs" work that was discussed recently, but obviously we'll have to wait for that to actually land. |
I am skeptical, and think it could be a long wait, especially to get it upstream. |
(Also I would seriously suggest that this is functionality that should be exposed through a runtime-specific annotation and not a first-class field in |
how would it work with rootless containers or in general with IDs that are not mapped in the current namespace? I guess rootless containers won't still be able to map arbitrary IDs from the host. |
Hello @cyphar , Thanks for letting me know, |
This feature has become very popular in Rootless Podman, We are seeing lots of users that need access to files and devices, via supplemental groups. We have recently made this a first class feature of podman. podman run --group-add keep-id ... Currently this is only supported in crun, and we would love to get it to work in runc. I would hope in the future we had better support, where we could keep access to the groups as well as add groups within the user namespace, but for now this fixes a key issue rootless users are hitting. I think we see this a lot more in enterprise customers then we even see in wild. |
As an unprivileged user on a host, I have read/write access to various files, some via ownership and some via group membership. I know there are technical reasons, but I think the security model should be considered differently in different contexts. Sometimes a container is used to isolate and contain an external application (i.e. something pulled from a repository) in a controlled environment and you don't want it to see or touch anything outside. But in other cases (Singularity, rootless podman), you as the user are already "outside" and you're choosing to contain yourself , so you should have full control of how that happens and how to invoke the containment tool; the same security considerations do not apply since you can already do whatever you want on the host. |
I want to add as the sysadmin of a HPC batch cluster at a major biomed academic center, this secondary group issue is the primary reason we are using Singularity rather than rootless podman. We use secondary groups extensively for various users and group to work together on sensitive data sets. Containers are used to run analysis programs like Tensorflow from NVIDIA NGC or distributed docker images of apps built on (for example) Ubuntu 20 that otherwise cannot run on the RHEL7 nodes. |
If it can be useful for you: Podman when used together with crun supports the |
crun is not available on RHEL7 that I can find There is an oddness on CentOS8 Stream box $ rpm -q podman The 'nogroup' thing is wierd (singularity reports the groups normally) and I don't understand why I can cd to /gptest (read access) but not write. |
It is not available on RHEL7. I think you need to specify the |
Unfortunately still not quite right:
So actually it is 'x' bit that works for the cd, but 'r' and 'w' do not. But one can read and write to existing files in the dir. Really wierd. |
There are cases where it would be necessary to skip the
setgroups(2)
syscall so that the original additional groups can be maintained.It can be used, for example, by rootless containers to keep access to a storage directory that is accessible only by a secondary group.
runc already skips the
setgroups
in some cases: either if the user had euid != 0 or if/proc/self/setgroups
is set todeny
. I'd like to add a third condition where thesetgroups
is skipped also if explicitly requested.Do we need a new field under
process/user
, e.g.keepOriginalGroups
? Would be enough to reuseadditionalGids
to have some special value (e.g.-1
to keep current groups)?The text was updated successfully, but these errors were encountered: