Feature to ignore chowns of /dev

[EddieX64]

Hello,

The problem arise when something inside the sysbox container is trying to chown devices in /dev. For instance, when i use the following Dockerfile

FROM registry.suse.com/suse/sle15:15.5
RUN zypper update -y

If SUSE base image is not latest version and contain outdated version of permissions package, zypper package manager will update it and permissions package will try to execute chown root:root on all devices in /dev that are not owned by root:

/dev/full
/dev/kmsg
/dev/null
/dev/random
/dev/tty
/dev/urandom
/dev/zero

This leads docker build to fail with an error exit code. Of course this can be avoided by using latest SUSE base image where permissions package is already updated, but it's not always possible. I read the sysbox docs and found some useful feature to ignore chown of /sys: https://github.com/nestybox/sysbox/blob/master/docs/user-guide/configuration.md#ignoring-chowns-of-sysfs
My question: is it possible to add the same feature for chowns of /dev?

[ctalledo]

Hi @EddieX64, thanks for filing the issue.

will try to execute chown root:root on all devices in /dev that are not owned by root

I think that's the crux of the issue: ideally the devices should already be owned by root:root inside the Sysbox container, but I can see several devices aren't:

/ # 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

Overcoming this is not that simple, it requires Sysbox to intercept the Linux mknod system call from inside the container, which is doable but is not yet implemented.

[ctalledo]

I've filed issue #850 to track this.

Closing there since the feature requested here is not the correct solution.

Thanks @EddieX64 for raising this up.