Bug#998051: initscripts: /dev/ptmx and /dev/pts/ptmx have wrong permissions after boot in lxc container

[Anton Khirnov]

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