Bug#756604: systemd: NoNewPrivileges allows UID changes, while the doc says it prohibits it
Control: retitle -1 Misleading documentation about NoNewPrivileges and UID changes Control: tag -1 + upstream Hi, Ansgar Burchardt wrote (31 Jul 2014 09:53:21 GMT) : It works as intended, but the documentation might be a bit misleading. NoNewPrivileges only affects the exec syscall which will no longer grant any new privileges, including no longer switching uid for suid binaries. It does *not* take away the CAP_SETUID or any other capabilities the process already has. Thanks a lot! I'll report a bug upstream (possibly with a patch) wrt. the documentation being a bit misleading, then. Cheers, -- intrigeri ___ 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#756604: systemd: NoNewPrivileges allows UID changes, while the doc says it prohibits it
Hi again, Ansgar Burchardt wrote (31 Jul 2014 10:04:52 GMT) : Oh, and one other thing that might be worth mentioning in this context: | Be careful, though: LSMs might also not tighten constraints on exec | in no_new_privs mode. (This means that setting up a general-purpose | service launcher to set no_new_privs before execing daemons may | interfere with LSM-based sandboxing.) +--[ Documentation/prctl/no_new_privs.txt ] I have no idea about LSMs, but I would expect this to only matter if you either rely on the kernel to setup the sandbox for the service (and do not use AppArmorProfile=) or if the service executes programs that should have even tigher restrictions. Both of which should not affect services like tor, but might be relevant for others. Indeed, this won't affect the tor service: my intention is to use AppArmorProfile= in its unit file as soon as systemd v210+ is available in Debian, to replicate how we're doing it in the initscript. I'll double-check once we're at this point, though. Cheers, -- intrigeri ___ 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: bug 756604 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=81959
Processing commands for cont...@bugs.debian.org: forwarded 756604 https://bugs.freedesktop.org/show_bug.cgi?id=81959 Bug #756604 [systemd] Misleading documentation about NoNewPrivileges and UID changes Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=81959'. thanks Stopping processing here. Please contact me if you need assistance. -- 756604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756604 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#756725: systemd: should reboot even it umount / fails
Package: systemd Version: 44-11+deb7u4 Severity: normal Today I had a server fail to restart when I ran the reboot command. When I got to it I saw the following on the console: Could not remount as read-only /: Device or resource busy Not all file systems unmounted, 1 left. Cannot finalize remaining file systems and devices, giving up. Then it hung, presumably indefinitely. I think it should do a forced reboot in that situation so that we have a usable system. Having it hang on a shutdown would usually be OK but on a reboot the sysadmin wants the system to run again. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii dpkg 1.16.15 ii initscripts 2.88dsf-41+deb7u1 ii libacl1 2.2.51-8 ii libaudit01:1.7.18-1.1 ii libc62.19-7 ii libcap2 1:2.22-1.2 ii libcryptsetup4 2:1.4.3-4 ii libdbus-1-3 1.6.8-1+deb7u3 ii libkmod2 9-3 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.3-7.1 ii libselinux1 2.1.9-5 ii libsystemd-daemon0 44-11+deb7u4 ii libsystemd-id128-0 44-11+deb7u4 ii libsystemd-journal0 44-11+deb7u4 ii libsystemd-login044-11+deb7u4 ii libudev0 175-7.2 ii libwrap0 7.6.q-24 ii udev 175-7.2 ii util-linux 2.20.1-5.3 Versions of packages systemd recommends: ii libpam-systemd 44-11+deb7u4 Versions of packages systemd suggests: ii python2.7.8-1 pn python-cairo none pn python-dbus none pn systemd-gui none -- Configuration Files: /etc/systemd/systemd-journald.conf changed: [Journal] SystemMaxUse=50M ImportKernel=no -- 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
