I’m building an image based on balenalib/intel-nuc-ubuntu:bionic-20191011 that connects to a USB camera, so I set UDEV=1. However, when I test run the container on my development machine (Ubuntu Bionic host; an advantage of building for the same architecture), it kills the ability to open new gnome-terminal’s with the error “There was an error creating the child process for this terminal. Failed to open PTY: Permission denied” until the system is rebooted.
I’m not that familiar with udev, so any idea why that is happening, and if there’s a way to stop it? It’s not the end of the world if we have to bind mount /dev on our development machines, and use UDEV=1 on Balena, but I’m more concerned about whether it might also limit opening terminals on the device itself.
It can be a case our base images (ran in privileged mode and UDEV on) modify the permission of the ptmx node. Which makes any opening of a pseudo terminal impossible until the permissions are fixed (see how our base images handle udev in the entry script https://github.com/balena-io-library/base-images/blob/master/scripts/assets/entry.sh#L14-L52). Can you please add chmod 666 /dev/pts/ptmx to fix the permission issue and let us know the result?
Thanks for the tip. When I run chmod 666 /dev/pts/ptmx in the host, it does indeed fix the problem (and even rerunning the container does not reset it), however, I cannot prevent it by simply running chmod 666 /dev/pts/ptmx in entry.sh.
Digging further into the entry script, the problem happens at this command: https://github.com/balena-io-library/base-images/blob/master/scripts/assets/entry.sh#L33. The issue is that the link overwrites /dev/ptmx on the host, which is originally a “device file” with read/write permissions, with a link to /dev/pts/ptmx, which is a different “device file” with no permissions.
Ie, before the ln command is run (output from the host):
crw-rw-rw- 1 root tty 5, 2 Oct 30 09:14 ptmx
$ ls -l /dev/pts/ | grep ptmx
c--------- 1 root root 5, 2 Oct 30 09:03 ptmx
And after:
lrwxrwxrwx 1 root root 13 Oct 30 09:14 ptmx -> /dev/pts/ptmx
$ ls -l /dev/pts/ | grep ptmx
c--------- 1 root root 5, 2 Oct 30 09:03 ptmx
I don’t know why those two ptmx's are not linked originally, or the implications of overwriting it, but that’d definitely causing the problem. Running chmod 666 /dev/pts/ptmx from within the container afterwards only changes the permissions inside the container, and does not affect the /dev/pts/ptmx in the host (presumably because of some of the things mount_dev() does)