Package: initscripts Version: 2.96-7 Severity: normal Dear Maintainer, upon booting with sysvinit in an LXC container, /dev/ptmx and /dev/pts/ptmx have the permissions of 000, making them unusable (typically they should be 666).
There seem to be several factors contributing to the problem, not sure which one is the main one. 1) Initially within this setup, the mounts of various "system" filesystems (including /dev/pts) are done by LXC, with the correct permissions of 666. 2) During init, starting mountdevsubfs tries to mount /dev/pts again, which apparently does not break anything (did not investigate in detail why, perhaps the kernel special-cases this). 3) When checkroot runs, it executes '/etc/init.d/mountdevsubfs.sh reload' at the very end of do_start() (which tries to remount /dev/pts, as opposed to just mounting it) and it is this invocation that causes the permissions to break. The reason why remount fails is that it passes the original options to the mount call. I believe it obtains these options from the kernel, but the kernel reports the UID/GID values as visible from the outside of the container (i.e. in the host's userns). E.g. the relevant /proc/self/mountinfo line inside the container can be 201 339 0:97 / /dev/pts rw,nosuid,noexec,relatime - devpts devpts rw,gid=231077,mode=620,ptmxmode=666,max=1024 where 231072 is the start of the UID range mapped to that container. However when the gid option is passed to the mount call, it is expected to be in the container's userns, so the kernel tries to remap this value to the global (i.e. the host's) range, which obviously fails, thus failing the remount. Upon this failure, the ptmx permissions are reset to the default value of 000. I see two issues there: 1) Why does mountinfo contain the host's UID values rather than the container's? Looking at the relevant kernel code [fs/devpts/inode.c:devpts_show_options()] suggests that they should be remapped into the container's range. I cannot say whether my understanding is wrong, or this behavior is buggy. 2) Why does checkroot reload mountdevsubfs? The comment says 'Update mount options for mounts created in early boot', but it is not clear to me what options can be updated by this and why is this needed. Commenting out the reload in checkroot.sh fixes the issue for me, but I'd rather not have local modifications. Cheers, -- Anton Khirnov -- System Information: Debian Release: 11.1 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'oldstable-debug'), (500, 'stable'), (500, 'oldstable'), (400, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages initscripts depends on: ii lsb-base 11.1.0 ii sysv-rc 2.96-7 Versions of packages initscripts recommends: ii e2fsprogs 1.46.2-2 ii psmisc 23.4-2 initscripts suggests no packages. -- Configuration Files: /etc/default/rcS changed [not included] /etc/rc.local changed [not included] -- no debconf information
