container devpts is broken with modern guest distros

[grawity]

For some distributions, commit 03cfe0d appears to have completely broken pty allocation for non-root processes; I've seen this reported on IRC several times.

In the past, a new pty would be initially owned by root, and glibc would call the /usr/lib/pt_chown setuid helper to change ownership to the caller's UID. But devpts already creates ptys owned by the correct uid (and has done so for many years), so recent glibc versions no longer include pt_chown.

However, nspawn now mounts /dev/pts with an uid= explicitly specified, which forces devpts to always create ptys owned by the fixed uid 5. This means non-root programs can no longer use the ptys they create.

(In older distributions, pt_chown is still included, and it "hides" the problem. Also, having gid=5 is ok; the bug is specifically about uid=.)

Quick test: exec {fd}</dev/ptmx && ls -l /dev/pts/ && exec {fd}<&-

[poettering]

So this would mean we'd have to drop the uid= mount option and instead chown() the ptmx file in it manually... Yuck.

[floppym]

Why do you need to chown it?

It seems to work properly if I simply remove the uid= from setup_pts. I see this in the container:

# systemd-nspawn --register=no --directory=/chroots/foo --private-users=65536

# mount | grep devpts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=65541,mode=620,ptmxmode=666)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

# ls -ldn /dev/pts
drwxr-xr-x 2 0 0 0 Jul 16 20:29 /dev/pts

# ls -ln /dev/pts/ptmx
crw-rw-rw- 1 0 0 5, 2 Jul 16 20:29 ptmx

openpty(3) and posix_openpt(3) also start working, both with and without private-users.

[poettering]

@floppym What if you look at the file owners of all files in the /dev/pts instance? i.e. even after creating an additional pty in it?

Happy to take a patch that drops the mount option if indeed the devpts root dir, as well as all nodes inside it are owned properly anyway if --private-users= is used. But please verify that!

[floppym]

What if you look at the file owners of all files in the /dev/pts instance? i.e. even after creating an additional pty in it?

That seems to work properly too. Here's what that looks like with --private-users=65536. Kindly ignore the openrc/portage names; it's just a container that I happened to have handy for doing testing on Gentoo.

portage@openrc /dev/pts $ id
uid=250(portage) gid=250(portage) groups=250(portage)

portage@openrc /dev/pts $ mount | grep devpts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=65541,mode=620,ptmxmode=666)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

portage@openrc /dev/pts $ /usr/local/devel/posix_openpt &
[1] 56

portage@openrc /dev/pts $ ls -la
total 0
drwxr-xr-x 2 root    root      0 Jul 22 22:14 .
drwxr-xr-x 5 root    root    360 Jul 22 22:14 ..
crw--w---- 1 portage tty  136, 0 Jul 22 22:28 0
crw-rw-rw- 1 root    root   5, 2 Jul 22 22:14 ptmx

posix_openpt is just a dumb program that allocates a pty and sleeps for 10 seconds.

I'll create a pull request in a bit.

[floppym]

Also worth noting that grawity's simple test case works as well.

portage@openrc ~ $ exec {fd}</dev/ptmx && ls -l /dev/pts/ && exec {fd}<&-
total 0
crw--w---- 1 portage tty  136, 0 Jul 22 22:44 0
crw-rw-rw- 1 root    root   5, 2 Jul 22 22:14 ptmx