podman: Rootless podman using --device and --group-add keep-groups not working as expected
Description
I am trying to understand how to properly use --device in a rootless podman container.
Currently, when I added a device to the rootless container I see that the device is owned by: nobody nogroup
$ ls -la /dev/
...
crw-rw---- 1 nobody nogroup 505, 1 Apr 26 18:32 nvhost-as-gpu
...
I have seen this on the troubleshooting: https://github.com/containers/podman/blob/master/troubleshooting.md#20-passed-in-device-cant-be-accessed-in-rootless-container
But this is only a solition for crun is there one for runc?
I have pulled the latest podman and have attempted to use:
http://docs.podman.io/en/latest/markdown/podman-run.1.html#device-host-device-container-device-permissions
--group-add keep-groups
But this does not seem to change behavior, I still see the device is owned by: nobody nogroup
I believe this issue is preventing me from accessing my GPU in a rootless container. See here if you want specific details: https://github.com/NVIDIA/nvidia-container-runtime/issues/85#issuecomment-827750602
What are my options? Do I need to migrate to crun? Will that work? Should this be working with runc and --group-add?
Steps to reproduce the issue:
-
podman run -it --device </dev/some-mnt>:</dev/some-mnt> --group-add keep-groups <image>
-
$ ls -la /dev
-
Output will show device is owned by
nobody nogroup -
I have also tried with
--group-add videowith no luck either.
Describe the results you received:
$ ls -la /dev/
...
crw-rw---- 1 nobody nogroup 505, 1 Apr 26 18:32 nvhost-as-gpu
...
Describe the results you expected:
I would expect to be able to see the video group.
$ ls -la /dev/
...
crw-rw---- 1 nobody video 505, 1 Apr 26 18:32 nvhost-as-gpu
...
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
$ podman --version
podman version 3.2.0-dev
Output of podman info --debug:
podman --storage-driver=vfs --root /data/podman-root/ --runroot /data/podman-run-root/ info --debug
host:
arch: arm64
buildahVersion: 1.20.1-dev
cgroupManager: cgroupfs
cgroupVersion: v1
conmon:
package: Unknown
path: /usr/local/libexec/podman/conmon
version: 'conmon version 2.0.28-dev, commit: 3770524c7d9c95fe703460a9168350ee5db7be03'
cpus: 8
distribution:
distribution: tegra-ubuntu
version: "18.04"
eventLogger: file
hostname: ubuntu
idMappings:
gidmap:
- container_id: 0
host_id: 1001
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
kernel: 4.9.140
linkmode: dynamic
memFree: 27120275456
memTotal: 33338081280
ociRuntime:
name: runc
package: 'runc: /usr/sbin/runc'
path: /usr/sbin/runc
version: 'runc version spec: 1.0.1-dev'
os: linux
remoteSocket:
path: /run/user/1000/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_AUDIT_WRITE,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_MKNOD,CAP_NET_BIND_SERVICE,CAP_NET_RAW,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
selinuxEnabled: false
slirp4netns:
executable: /data/downloads/slirp4netns/slirp4netns
package: Unknown
version: |-
slirp4netns version 1.1.9
commit: 4e37ea557562e0d7a64dc636eff156f64927335e
libslirp: 4.4.0
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.3.3
swapFree: 16669016064
swapTotal: 16669016064
uptime: 45h 22m 54.28s (Approximately 1.88 days)
registries:
search:
- docker.io
- registry.fedoraproject.org
- registry.access.redhat.com
store:
configFile: /home/<username>/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: vfs
graphOptions: {}
graphRoot: /data/podman-root
graphStatus: {}
imageStore:
number: 0
runRoot: /data/podman-run-root
volumePath: /data/podman-root/volumes
version:
APIVersion: 3.2.0-dev
Built: 1619474073
BuiltTime: Mon Apr 26 21:54:33 2021
GitCommit: 2039be00d12afaab84659619c47a463cacb039f5
GoVersion: go1.16
OsArch: linux/arm64
Version: 3.2.0-dev
Package info (e.g. output of rpm -q podman or apt list podman):
I built podman from source for ubuntu 18.04 on ARM
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)
Yes
Additional environment details (AWS, VirtualBox, physical, etc.): Physical
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (10 by maintainers)
Commits related to this issue
- Fix troubleshooting documentation on handling sublemental groups. Fixes: https://github.com/containers/podman/issues/10166 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com> — committed to rhatdan/podman by rhatdan 3 years ago
- Fix troubleshooting documentation on handling sublemental groups. Fixes: https://github.com/containers/podman/issues/10166 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com> — committed to rhatdan/podman by rhatdan 3 years ago
Sorry for asking in an already closed issue, but I cannot find more information about this.
Does
keep-groupskeep all extra groups? Or is there a limit?It does definitely increase the privileges allowed to the container - the container process, if it breaks out of the container, now has access to the groups of the user that launched Podman, which could potentially include important ones (wheel, for example)