system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-09-06 16:56:43 +00:00
Code Issues Packages Projects Releases Wiki Activity
systemd/test/units/testsuite-20.sh

167 lines
5.1 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 09:35:06 +00:00
#!/usr/bin/env bash
tests: add spdx headers to scripts and Makefiles
2021-10-17 16:13:06 +00:00
# SPDX-License-Identifier: LGPL-2.1-or-later
test: use set -eux and set -o pipefail everywhere This should make the scripts more robust.
2021-04-09 17:39:41 +00:00
set -eux
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 11:20:22 +00:00
set -o pipefail
test: use newer verb to set log levels
2019-04-03 06:19:08 +00:00
systemd-analyze log-level debug
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 11:20:22 +00:00
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00: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 07:32:28 +00:00
systemd-run -p DynamicUser=1 --unit=test20-sleep.service /bin/sleep infinity
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
# Update our own main PID to the external test PID, this should work
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00:00
systemd-notify MAINPID="$EXTERNALPID"
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 11:20:22 +00:00
# Update our own main PID to the internal test PID, this should work, too
systemd-notify MAINPID=$INTERNALPID
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
# Update it back to our own PID, this should also work
systemd-notify MAINPID=$$
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
# Try to set it to PID 1, which it should ignore, because that's the manager
systemd-notify MAINPID=1
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
# Try to set it to PID 0, which is invalid and should be ignored
systemd-notify MAINPID=0
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00: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: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
codespell: fix spelling errors
2019-04-27 00:22:40 +00: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.
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00:00
systemd-notify --uid=1000 MAINPID="$EXTERNALPID"
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 11:20:22 +00:00
codespell: fix spelling errors
2019-04-27 00:22:40 +00: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.
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00:00
systemd-notify --uid=1000 MAINPID="$INTERNALPID"
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 11:20:22 +00:00
# Update it back to our own PID, this should also work
systemd-notify --uid=1000 MAINPID=$$
test: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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 09:35:06 +00: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 11:20:22 +00: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
TEST-*: use spacing before redirection operator, but not after << EOF → <<EOF > foo < bar → >foo <bar
2021-04-07 22:09:55 +00:00
echo \$MAINPID >/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 11:20:22 +00:00
EOF
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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 11:20:22 +00:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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 09:35:06 +00: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 11:20:22 +00: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
TEST-*: use spacing before redirection operator, but not after << EOF → <<EOF > foo < bar → >foo <bar
2021-04-07 22:09:55 +00:00
echo \$MAINPID >/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 11:20:22 +00:00
chown 1001:1001 /run/mainpidsh2/pid
EOF
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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 11:20:22 +00:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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: replace the obsolete `` syntax with $()
2021-04-09 17:54:42 +00: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 11:20:22 +00:00
test: move TEST-20-MAINPIDGAMES setup to static files
2019-12-10 07:32:28 +00: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 09:35:06 +00: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 11:20:22 +00: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 07:32:28 +00: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 11:20:22 +00:00
TEST-*: make failure tests actually fail on failure Here the intent was actually correct, and the tests still pass when the check is made effective.
2021-04-07 23:27:33 +00: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.
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 \
&& { echo 'unexpected success'; exit 1; }
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 11:20:22 +00:00
# Test that this failed due to timeout, and not some other error
test: use quotes where necessary to avoid possible word splitting.
2021-04-09 17:49:32 +00: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 11:20:22 +00:00
test: add regression test for systemd-run --scope [--user] systemd-run --scope --user failed to run in system 249.6, cf. #21297. Add tests for systemd-run --scope and systemd-run --scope --user to make sure this does not regress again.
2021-11-11 21:25:40 +00:00
# Test that scope units work
systemd-run --scope --unit test20-true.scope /bin/true
test "$(systemctl show -P Result test20-true.scope)" = success
# Test that user scope units work as well
runas() {
declare userid=$1
shift
# shellcheck disable=SC2016
su "$userid" -s /bin/sh -c 'XDG_RUNTIME_DIR=/run/user/$UID exec "$@"' -- sh "$@"
}
systemctl start user@4711.service
runas testuser systemd-run --scope --user --unit test20-true.scope /bin/true
test "$(systemctl show -P Result test20-true.scope)" = success
test: use newer verb to set log levels
2019-04-03 06:19:08 +00: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 11:20:22 +00:00
TEST-*: use spacing before redirection operator, but not after << EOF → <<EOF > foo < bar → >foo <bar
2021-04-07 22:09:55 +00:00
echo OK >/testok
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 11:20:22 +00:00
exit 0
Reference in a new issue Copy permalink