Bug#837893: systemd: Logging from gnome session is passed on to all syslog facilities
Control: tags -1 + patch On Thu, 15 Sep 2016 11:15:29 +0200 Matijs van Zuijlen wrote: > Package: systemd > Version: 231-6 > Severity: normal > > Since recently, log messages from programs running under the gnome > session have started appearing in all logs in /var/logs, including > /var/logs/kern.log, even though my rsyslog configuration has not > changed, and correctly only routes kern.* there. > > This is very annoying since it fills the logs with messages that don't > belong there, and makes running logcheck tedious. > > It seems this is a recent regression, since before I was able to route > these messages to a low-priority log using the following rsyslog > configuration: > > user.=info;user.=notice;\ > user.=warn -/var/log/user-low.log > > If I look at the messages directly with journalctl -o verbose, it seems > they do not set the syslog facility, which should make them end up with > user facility, but doesn't. > Patch posted upstream at https://github.com/systemd/systemd/pull/5667 -- 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 ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: systemd: Logging from gnome session is passed on to all syslog facilities
Processing control commands: > tags -1 + patch Bug #837893 [systemd] systemd: Logging from gnome session is passed on to all syslog facilities Bug #858399 [systemd] rsyslog: numerous packages appear to be syslogging with facility=KERN Added tag(s) patch. Added tag(s) patch. -- 837893: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837893 858399: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858399 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: fixed 858986 in 233-1
Processing commands for cont...@bugs.debian.org: > fixed 858986 233-1 Bug #858986 [systemd-container] systemd-container: systemd-nspawn fails to spawn container from a read-only image There is no source info for the package 'systemd-container' at version '233-1' with architecture '' Unable to make a source version for version '233-1' Marked as fixed in versions 233-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 858986: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858986 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#859003: systemd-container: strange permissions on /dev/pts/ptmx
On Thu, 30 Mar 2017 01:00:33 AM Felipe Sateler wrote: > 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. > > [1] https://www.kernel.org/doc/Documentation/filesystems/devpts.txt Fair point. So why does systemd-nspawn do things differently than the host in this regard? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#859003: systemd-container: strange permissions on /dev/pts/ptmx
On Wed, Mar 29, 2017 at 10:07 AM, Russell Coker 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. [1] https://www.kernel.org/doc/Documentation/filesystems/devpts.txt -- Saludos, Felipe Sateler ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#859003: systemd-container: strange permissions on /dev/pts/ptmx
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 libblkid12.29.2-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-9 ii libcurl3-gnutls 7.52.1-3 ii libgcrypt20 1.7.6-1 ii libip4tc01.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-progs4.9.1-1 pn libnss-mymachines systemd-container suggests no packages. -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#858986: systemd-container: systemd-nspawn fails to spawn container from a read-only image
Package: systemd-container Version: 232-19 Severity: normal Dear Maintainer, systemd-nspawn fails to spawn a container from an image which has a read-only file system as root partition (SquashFS): $ systemd-nspawn -i foo.img Spawning container foo.img on /home/felix/foo.img. Press ^] three times within 1s to kill container. Failed to create directory /tmp/nspawn-root-jvD8mU/sys: Read-only file system I filed the bug upstream [0] and it was fixed in systemd v233 [1]. Please consider backporting the patch to stretch. [0]: https://github.com/systemd/systemd/issues/4711 [1]: https://github.com/systemd/systemd/commit/acbbf69b718260755a5dff60dd68ba239ac0d61b -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (600, 'testing'), (499, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash 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 libblkid12.29.1-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-9 ii libcurl3-gnutls 7.52.1-3 ii libgcrypt20 1.7.6-1 ii libip4tc01.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-19 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages systemd-container recommends: ii btrfs-progs4.7.3-1 ii btrfs-tools4.7.3-1 ii libnss-mymachines 232-19 systemd-container suggests no packages. -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
