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
Inside a Sysbox container, some devices show up with nobody:nogroup ownership:
/ # ls -l /dev | grep nobody
crw-rw-rw- 1 nobody nobody 1, 7 Oct 10 01:13 full
crw-rw-rw- 1 nobody nobody 1, 3 Oct 10 01:13 kmsg
drwxrwxrwt 2 root nobody 40 Oct 10 02:11 mqueue
crw-rw-rw- 1 nobody nobody 1, 3 Oct 10 01:13 null
crw-rw-rw- 1 nobody nobody 1, 8 Oct 10 01:13 random
crw-rw-rw- 1 nobody nobody 5, 0 Oct 10 02:41 tty
crw-rw-rw- 1 nobody nobody 1, 9 Oct 10 01:13 urandom
crw-rw-rw- 1 nobody nobody 1, 5 Oct 10 01:13 zero
This is not ideal and sometimes causes problems (e.g., issue #839 ).
Ideally all these devices would show up with root:root ownership, as they would on a real host.
This likely requires that Sysbox intercept the mknod system call inside the container, as otherwise this syscall is blocked within the Sysbox container's user namespace.
The text was updated successfully, but these errors were encountered:
Either that, or we run mknod in the init namespaces (through sys-mgr) and bind-mount these nodes into each container. I like the idea of intercepting mknod though since it offers a better virtual-host abstraction.
Inside a Sysbox container, some devices show up with
nobody:nogroup
ownership:This is not ideal and sometimes causes problems (e.g., issue #839 ).
Ideally all these devices would show up with
root:root
ownership, as they would on a real host.This likely requires that Sysbox intercept the
mknod
system call inside the container, as otherwise this syscall is blocked within the Sysbox container's user namespace.The text was updated successfully, but these errors were encountered: