systemd/test/TEST-20-MAINPIDGAMES/test.sh

#!/usr/bin/env bash
# SPDX-License-Identifier: LGPL-2.1-or-later
set -e

TEST_DESCRIPTION="test changing main PID"

# shellcheck source=test/test-functions
. "${TEST_BASE_DIR:?}/test-functions"

do_test "$@"
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`
tests: add spdx headers to scripts and Makefiles 2021-10-17 19:13:06 +03:00			`# SPDX-License-Identifier: LGPL-2.1-or-later`
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 -e`
test: make the test entrypoint scripts shellcheck-compliant 2021-04-19 14:01:59 +03:00
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_DESCRIPTION="test changing main PID"`

test: make the test entrypoint scripts shellcheck-compliant 2021-04-19 14:01:59 +03:00			`# shellcheck source=test/test-functions`
			`. "${TEST_BASE_DIR:?}/test-functions"`
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: "detect" the test number automagically Specifying the test number manually is tedious and prone to errors (as recently proven). Since we have all the necessary data to work out the test number, let's do it automagically. 2021-04-26 20:20:18 +03:00			`do_test "$@"`