Your message dated Tue, 12 Mar 2019 03:40:29 +0100
with message-id <[email protected]>
and subject line Re: Bug#859003: systemd-container: strange permissions on
/dev/pts/ptmx
has caused the Debian Bug report #859003,
regarding systemd-container: strange permissions on /dev/pts/ptmx
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
859003: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859003
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd-container
Version: 232-22
Severity: normal
# grep pts /proc/mounts
devpts /dev/pts devpts
rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
# ls -l /dev/pts/ptmx
c---------. 1 root root 5, 2 Mar 20 21:51 /dev/pts/ptmx
The above is from a regular Debian/unstable shell.
# grep pts /proc/mounts
devpts /dev/pts devpts
rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
# ls -l /dev/pts/ptmx
crw-rw-rw-. 1 root root 5, 2 Mar 30 2017 /dev/pts/ptmx
The above is from a shell run from a chroot managed by systemd-nspawn. I have
systemd-nspawn starting the below shell script that runs sshd, so nothing in
the chroot environment has any effect on mount options.
Why does the virtual environment created by systemd-nspawn have different
permissions for /dev/pts/ptmx than the outside environment? I am not claiming
that what systemd-nspawn is doing is inherently wrong (it might be the correct
thing for other distributions), but I believe that it should be consistent with
the main Debian environment. It is plausible that systemd-nspawn is correct
here and the rest of Debian is wrong, if so please reassign the bug
appropriately. But as a security person I'm leaning towards minimum privileges
being the correct choice, which means mode 0 would be correct and mode 666
(as used by systemd-nspawn) would be a bug.
#!/bin/bash
set -e
restorecon -R /dev
mkdir -p /var/run/sshd
restorecon -R /var/run
/usr/sbin/sshd -D
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages systemd-container depends on:
ii dbus 1.10.16-1
ii libacl1 2.2.52-3+b1
ii libblkid1 2.29.2-1
ii libbz2-1.0 1.0.6-8.1
ii libc6 2.24-9
ii libcurl3-gnutls 7.52.1-3
ii libgcrypt20 1.7.6-1
ii libip4tc0 1.6.0+snapshot20161117-5
ii liblzma5 5.2.2-1.2+b1
ii libseccomp2 2.3.1-2.1
ii libselinux1 2.6-3+b1
ii systemd 232-22
ii zlib1g 1:1.2.8.dfsg-5
Versions of packages systemd-container recommends:
ii btrfs-progs 4.9.1-1
pn libnss-mymachines <none>
systemd-container suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
On Wed, 29 Mar 2017 11:00:33 -0300 Felipe Sateler <[email protected]>
wrote:
> On Wed, Mar 29, 2017 at 10:07 AM, Russell Coker <[email protected]> wrote:
> > Package: systemd-container
> > Version: 232-22
> > Severity: normal
> >
> > # grep pts /proc/mounts
> > devpts /dev/pts devpts
> > rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
> > # ls -l /dev/pts/ptmx
> > c---------. 1 root root 5, 2 Mar 20 21:51 /dev/pts/ptmx
> >
> > The above is from a regular Debian/unstable shell.
> >
> > # grep pts /proc/mounts
> > devpts /dev/pts devpts
> > rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
> > # ls -l /dev/pts/ptmx
> > crw-rw-rw-. 1 root root 5, 2 Mar 30 2017 /dev/pts/ptmx
> >
> > The above is from a shell run from a chroot managed by systemd-nspawn. I
> > have
> > systemd-nspawn starting the below shell script that runs sshd, so nothing in
> > the chroot environment has any effect on mount options.
> >
> > Why does the virtual environment created by systemd-nspawn have different
> > permissions for /dev/pts/ptmx than the outside environment? I am not
> > claiming
> > that what systemd-nspawn is doing is inherently wrong (it might be the
> > correct
> > thing for other distributions), but I believe that it should be consistent
> > with
> > the main Debian environment. It is plausible that systemd-nspawn is correct
> > here and the rest of Debian is wrong, if so please reassign the bug
> > appropriately. But as a security person I'm leaning towards minimum
> > privileges
> > being the correct choice, which means mode 0 would be correct and mode 666
> > (as used by systemd-nspawn) would be a bug.
>
> From the kernel documentation:
>
> > As an option instead of placing a /dev/ptmx device node at /dev/ptmx
> > it is possible to place a symlink to /dev/pts/ptmx at /dev/ptmx or
> > to bind mount /dev/ptx/ptmx to /dev/ptmx. If you opt for using
> > the devpts filesystem in this manner devpts should be mounted with
> > the ptmxmode=0666, or chmod 0666 /dev/pts/ptmx should be called.
>
> And indeed nspawn sets up /dev/ptmx as a symlink, while debian host
> does not do that. In the host, /dev/ptmx has 0666 permissions.
>
I don't see anything obviously wrong with using a symlink here, so
closing the bug report.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
