In case of running test-execute on systems with systemd < v232, several
tests like privatedevices or protectkernelmodules fail because
/run/systemd/inaccessible/ doesn't exist. In these cases, we should skip
tests to avoid unnecessary errors.
See also https://github.com/systemd/systemd/pull/4243#issuecomment-253665566
Previously, we had two enums ManagerRunningAs and UnitFileScope, that were
mostly identical and converted from one to the other all the time. The latter
had one more value UNIT_FILE_GLOBAL however.
Let's simplify things, and remove ManagerRunningAs and replace it by
UnitFileScope everywhere, thus making the translation unnecessary. Introduce
two new macros MANAGER_IS_SYSTEM() and MANAGER_IS_USER() to simplify checking
if we are running in one or the user context.
The manpage of seccomp specify that using seccomp with
SECCOMP_SET_MODE_FILTER will return EACCES if the caller do not have
CAP_SYS_ADMIN set, or if the no_new_privileges bit is not set. Hence,
without NoNewPrivilege set, it is impossible to use a SystemCall*
directive with a User directive set in system mode.
Now, NoNewPrivileges is set if we are in user mode, or if we are in
system mode and we don't have CAP_SYS_ADMIN, and SystemCall*
directives are used.
We need to check the same thing in multiple tests. Use a shared
macro to make it easier to update the list of errnos.
Change the errno code for "unitialized cgroup fs" for ENOMEDIUM.
Exec format error looks like something more serious.
This fixes test-execute invocation in mock.
@evverx brought up that test-execute runs under MANAGER_USER which
forwards all its environment variables to the services. It turns out it
only forwards those that were in the environment at the time of manager
creation, so this test was still working.
It was still possible to attack it by running something like:
$ sudo VAR1=a VAR2=b VAR3=c ./test-execute
Prevent that attack by unsetting the three variables explicitly before
creating the manager for the test case.
Also add comments explaining the interactions with MANAGER_USER and,
while it has some caveats, this tests are still valid in that context.
Tested by checking that the test running with the variables set from the
external environment will still pass.
Check the base case, plus erasing the list, listing the same variable
name more than once and when variables are absent from the manager
execution environment.
Confirmed that `sudo ./test-execute` passes and that modifying the test
cases (or the values of the set variables in test-execute.c) is enough
to make the test cases fail.
When Group is set in the unit, the runtime directories are owned by
this group and not the default group of the user (same for cgroup paths
and standard outputs)
Fix#1231
It's primarily just a property of the Manager object after all, and we
try to refer to PID 1 as "manager" instead of "systemd", hence let's to
stick to this here too.
This patch removes includes that are not used. The removals were found with
include-what-you-use which checks if any of the symbols from a header is
in use.
This reverts commit 68e68ca810. We *need*
root access to create cgroups. The only exception is if it is run from
within a cgroup with "Delegate=yes". However, this is not always true and
we really shouldn't rely on this.
If your terminal runs from within a systemd --user instance, you're fine.
Everyone else is not (like running from ssh, VTs, and so on..).
Lennart Poettering