Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver 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 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 ?
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’.
