Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver <m...@netris.org> skribis: >> >>> ====================================================================== >>> ERROR: test_fork (test.test_pty.PtyTest) >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File >>> "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/test/test_pty.py", >>> line 116, in test_fork >>> pid, master_fd = pty.fork() >>> File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line >>> 107, in fork >>> master_fd, slave_fd = openpty() >>> File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line >>> 29, in openpty >>> master_fd, slave_name = _open_terminal() >>> File "/tmp/nix-build-python-3.3.3.drv-13/Python-3.3.3/Lib/pty.py", line >>> 70, in _open_terminal >>> raise os.error('out of pty devices') >>> OSError: out of pty devices >> >> This particular test is fixed by the daemon patch I posted, which makes >> sure /dev/pts/ptmx is 0666 (I’ll update nix-upstream.) > > What are the security implications of this? Why do you suppose that > Debian (or Linux, the kernel?) uses perms 0000 for /dev/pts/ptmx,
The devpts file system of Linux creates this file with perms 000 by default: https://www.kernel.org/doc/Documentation/filesystems/devpts.txt > and how it is that these tests normally work outside of guix-daemon, > when the perms are 0000? Often, outside the chroot, /dev/ptmx is directly a character device, with perms 0666. Conversely, inside the chroot it’s a symlink to /dev/pts/ptmx (as suggested in devpts.txt), but until this patch was applied, it had perms 000. Ludo’.