shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-25 23:21:33 +03:00
Code
dd2e9b7658
systemd-stable/test/units/testsuite-20.sh

140 lines
4.3 KiB
Bash
Raw Normal View History

treewide: more portable bash shebangs As in 2a5fcfae024ffc370bb780572279f45a1da3f946 and in 3e67e5c9928f8b1e1c5a63def88d53ed1fed12eb using /usr/bin/env allows bash to be looked up in PATH rather than being hard-coded. As with the previous changes the same arguments apply - distributions have scripts to rewrite shebangs on installation and they know what locations to rely on. - For tests/compilation we should rather rely on the user to have setup there PATH correctly. In particular this makes testing from git easier on NixOS where do not provide /bin/bash to improve compose-ability.
2020-03-04 12:35:06 +03:00
#!/usr/bin/env bash
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-05 14:20:22 +03:00
set -ex
set -o pipefail
test: use newer verb to set log levels
2019-04-03 09:19:08 +03:00
systemd-analyze log-level debug
systemd-analyze log-target console
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-05 14:20:22 +03:00
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
# Start a test process inside of our own cgroup
sleep infinity &
INTERNALPID=$!
disown
# Start a test process outside of our own cgroup
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
systemd-run -p DynamicUser=1 --unit=test20-sleep.service /bin/sleep infinity
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
EXTERNALPID=`systemctl show -P MainPID test20-sleep.service`
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-05 14:20:22 +03:00
# Update our own main PID to the external test PID, this should work
systemd-notify MAINPID=$EXTERNALPID
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $EXTERNALPID
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-05 14:20:22 +03:00
# Update our own main PID to the internal test PID, this should work, too
systemd-notify MAINPID=$INTERNALPID
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $INTERNALPID
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-05 14:20:22 +03:00
# Update it back to our own PID, this should also work
systemd-notify MAINPID=$$
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
# Try to set it to PID 1, which it should ignore, because that's the manager
systemd-notify MAINPID=1
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
# Try to set it to PID 0, which is invalid and should be ignored
systemd-notify MAINPID=0
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
# Try to set it to a valid but non-existing PID, which should be ignored. (Note
# that we set the PID to a value well above any known /proc/sys/kernel/pid_max,
# which means we can be pretty sure it doesn't exist by coincidence)
systemd-notify MAINPID=1073741824
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
codespell: fix spelling errors
2019-04-27 03:22:40 +03:00
# Change it again to the external PID, without privileges this time. This should be ignored, because the PID is from outside of our cgroup and we lack privileges.
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-05 14:20:22 +03:00
systemd-notify --uid=1000 MAINPID=$EXTERNALPID
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
codespell: fix spelling errors
2019-04-27 03:22:40 +03:00
# Change it again to the internal PID, without privileges this time. This should work, as the process is on our cgroup, and that's enough even if we lack privileges.
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-05 14:20:22 +03:00
systemd-notify --uid=1000 MAINPID=$INTERNALPID
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $INTERNALPID
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-05 14:20:22 +03:00
# Update it back to our own PID, this should also work
systemd-notify --uid=1000 MAINPID=$$
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID testsuite-20.service` -eq $$
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-05 14:20:22 +03:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
cat >/tmp/test20-mainpid.sh <<EOF
treewide: more portable bash shebangs As in 2a5fcfae024ffc370bb780572279f45a1da3f946 and in 3e67e5c9928f8b1e1c5a63def88d53ed1fed12eb using /usr/bin/env allows bash to be looked up in PATH rather than being hard-coded. As with the previous changes the same arguments apply - distributions have scripts to rewrite shebangs on installation and they know what locations to rely on. - For tests/compilation we should rather rely on the user to have setup there PATH correctly. In particular this makes testing from git easier on NixOS where do not provide /bin/bash to improve compose-ability.
2020-03-04 12:35:06 +03:00
#!/usr/bin/env bash
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-05 14:20:22 +03:00
set -eux
set -o pipefail
# Create a number of children, and make one the main one
sleep infinity &
disown
sleep infinity &
MAINPID=\$!
disown
sleep infinity &
disown
echo \$MAINPID > /run/mainpidsh/pid
EOF
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
chmod +x /tmp/test20-mainpid.sh
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-05 14:20:22 +03:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
systemd-run --unit=test20-mainpidsh.service -p StandardOutput=tty -p StandardError=tty -p Type=forking -p RuntimeDirectory=mainpidsh -p PIDFile=/run/mainpidsh/pid /tmp/test20-mainpid.sh
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID test20-mainpidsh.service` -eq `cat /run/mainpidsh/pid`
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-05 14:20:22 +03:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
cat >/tmp/test20-mainpid2.sh <<EOF
treewide: more portable bash shebangs As in 2a5fcfae024ffc370bb780572279f45a1da3f946 and in 3e67e5c9928f8b1e1c5a63def88d53ed1fed12eb using /usr/bin/env allows bash to be looked up in PATH rather than being hard-coded. As with the previous changes the same arguments apply - distributions have scripts to rewrite shebangs on installation and they know what locations to rely on. - For tests/compilation we should rather rely on the user to have setup there PATH correctly. In particular this makes testing from git easier on NixOS where do not provide /bin/bash to improve compose-ability.
2020-03-04 12:35:06 +03:00
#!/usr/bin/env bash
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-05 14:20:22 +03:00
set -eux
set -o pipefail
# Create a number of children, and make one the main one
sleep infinity &
disown
sleep infinity &
MAINPID=\$!
disown
sleep infinity &
disown
echo \$MAINPID > /run/mainpidsh2/pid
chown 1001:1001 /run/mainpidsh2/pid
EOF
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
chmod +x /tmp/test20-mainpid2.sh
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-05 14:20:22 +03:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
systemd-run --unit=test20-mainpidsh2.service -p StandardOutput=tty -p StandardError=tty -p Type=forking -p RuntimeDirectory=mainpidsh2 -p PIDFile=/run/mainpidsh2/pid /tmp/test20-mainpid2.sh
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P MainPID test20-mainpidsh2.service` -eq `cat /run/mainpidsh2/pid`
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-05 14:20:22 +03:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
cat >/dev/shm/test20-mainpid3.sh <<EOF
treewide: more portable bash shebangs As in 2a5fcfae024ffc370bb780572279f45a1da3f946 and in 3e67e5c9928f8b1e1c5a63def88d53ed1fed12eb using /usr/bin/env allows bash to be looked up in PATH rather than being hard-coded. As with the previous changes the same arguments apply - distributions have scripts to rewrite shebangs on installation and they know what locations to rely on. - For tests/compilation we should rather rely on the user to have setup there PATH correctly. In particular this makes testing from git easier on NixOS where do not provide /bin/bash to improve compose-ability.
2020-03-04 12:35:06 +03:00
#!/usr/bin/env bash
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-05 14:20:22 +03:00
set -eux
set -o pipefail
sleep infinity &
disown
sleep infinity &
disown
sleep infinity &
disown
# Let's try to play games, and link up a privileged PID file
ln -s ../mainpidsh/pid /run/mainpidsh3/pid
# Quick assertion that the link isn't dead
test -f /run/mainpidsh3/pid
EOF
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
chmod 755 /dev/shm/test20-mainpid3.sh
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-05 14:20:22 +03:00
# This has to fail, as we shouldn't accept the dangerous PID file, and then inotify-wait on it to be corrected which we never do
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 10:32:28 +03:00
! systemd-run --unit=test20-mainpidsh3.service -p StandardOutput=tty -p StandardError=tty -p Type=forking -p RuntimeDirectory=mainpidsh3 -p PIDFile=/run/mainpidsh3/pid -p DynamicUser=1 -p TimeoutStartSec=2s /dev/shm/test20-mainpid3.sh
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-05 14:20:22 +03:00
# Test that this failed due to timeout, and not some other error
test: use show -P in places Not all places are converted on purpose, to also test the other option name.
2020-04-01 19:32:30 +03:00
test `systemctl show -P Result test20-mainpidsh3.service` = timeout
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-05 14:20:22 +03:00
test: use newer verb to set log levels
2019-04-03 09:19:08 +03:00
systemd-analyze log-level info
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-05 14:20:22 +03:00
echo OK > /testok
exit 0
Copy Permalink