Lennart Poettering db256aab13 core: be stricter when handling PID files and MAINPID sd_notify() messages ... Let's be more restrictive when validating PID files and MAINPID= messages: don't accept PIDs that make no sense, and if the configuration source is not trusted, don't accept out-of-cgroup PIDs. A configuratin source is considered trusted when the PID file is owned by root, or the message was received from root. This should lock things down a bit, in case service authors write out PID files from unprivileged code or use NotifyAccess=all with unprivileged code. Note that doing so was always problematic, just now it's a bit less problematic. When we open the PID file we'll now use the CHASE_SAFE chase_symlinks() logic, to ensure that we won't follow an unpriviled-owned symlink to a privileged-owned file thinking this was a valid privileged PID file, even though it really isn't. Fixes: #6632		2018-01-11 15:12:16 +01:00
..
Makefile	core: be stricter when handling PID files and MAINPID sd_notify() messages	2018-01-11 15:12:16 +01:00
test.sh	core: be stricter when handling PID files and MAINPID sd_notify() messages	2018-01-11 15:12:16 +01:00
testsuite.sh	core: be stricter when handling PID files and MAINPID sd_notify() messages	2018-01-11 15:12:16 +01:00