You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my use case, I am doing a bind mount of devfs /dev into the container while also using a non-root container user. However, the GIDs between my host Linux system and the container are entirely different.
For example:
>>> ls -lA /dev/dri
total 0
drwxr-xr-x 2 root root 120 Oct 12 14:50 by-path
crw-rw----+ 1 root sudo 226, 0 Oct 12 14:50 card0
crw-rw----+ 1 root sudo 226, 1 Oct 12 14:50 card1
crw-rw-rw- 1 root 28 226, 128 Oct 12 14:50 renderD128
crw-rw-rw- 1 root 28 226, 129 Oct 12 14:50 renderD129
Hence, adding the user to group 44(video) would ofc still not let me access the video cards which are under group 27 on my host.
I am aware that updateRemoteUserUID doesn't change GIDs if it already exists in the container to avoid side effects. For my example, it would mean adding the container user to group "sudo", which may have unintended consequences.
However, I would like to suggest an option to forceRemoteUserUID that forces UID/GID regardless of whether the GID already exists in the container to get around this permission issue. Can just add a warning that the user should be aware of unintended side effects of adding the container user to arbitrary groups in the container. Thanks.
The text was updated successfully, but these errors were encountered:
Yes, I have seen #7284 and want to add onto it.
In my use case, I am doing a bind mount of devfs
/dev
into the container while also using a non-root container user. However, the GIDs between my host Linux system and the container are entirely different.For example:
Hence, adding the user to group 44(video) would ofc still not let me access the video cards which are under group 27 on my host.
I am aware that
updateRemoteUserUID
doesn't change GIDs if it already exists in the container to avoid side effects. For my example, it would mean adding the container user to group "sudo", which may have unintended consequences.However, I would like to suggest an option to
forceRemoteUserUID
that forces UID/GID regardless of whether the GID already exists in the container to get around this permission issue. Can just add a warning that the user should be aware of unintended side effects of adding the container user to arbitrary groups in the container. Thanks.The text was updated successfully, but these errors were encountered: