Should DevicePolicy affect execution of processes privileged using +?

[helmutg]

systemd version the issue has been seen with

252.4

Used distribution

Debian unstable

Linux kernel version used

No response

CPU architectures issue was seen on

None

Component

systemd-run

Expected behaviour you didn't see

No response

Unexpected behaviour you saw

No response

Steps to reproduce the problem

Consider the following invocations:

1$ systemd-run -p DevicePolicy=closed -p "ExecStartPre=/bin/sh -c ':>/dev/autofs'" true
2$ systemd-run -p "ExecStartPre=/bin/sh -c ':>/dev/autofs'" true
3$ systemd-run -p DevicePolicy=closed -p "ExecStartPre=+/bin/sh -c ':>/dev/autofs'" true

Expectation vs reality:

1. I expect this to fail the shell invocation, because the default device policy denies the device in question. It actually gets -EPERM on the open call. This works as expected.
2. I expect that his invocation works, because no device policy prevents the opening of /dev/autofs. It works as expected.
3. My and @bluca's intuition is that the + should disable sandboxing, so the DevicePolicy should not affect the shell. We actually see the same -EPERM as in the first case.

That raises the question of whether private devices should affect processes that have been privileged using the + prefix. The documentation is not clear about this aspect. It generally says that + causes the process to be executed "with full privileges" (in systemd.service). A number of directives (but not DevicePolicy or DeviceAllow) explain how + is affected by them. That leaves the intended semantics a bit unclear. If this behavior is intended, I suggest extending systemd.resource-control with a note explaining its interaction with +.

Additional program output to the terminal or log subsystem illustrating the issue

No response

[bluca]

So as it turns out, we never consider + for cgroup-based sandboxing options (devices, network). This is probably an oversight. It might be acceptable to fix it, given in practice it would relax the policy - ie nothing should stop working, as the implementation is stricter than it should be and we'd make it more open

[bluca]

Actually thinking about it, these are cgroup-based options, so disabling them would affect every process in the cgroup. The rest are process based, so each Exec* can have different settings. I'll clarify the docs.

[poettering]

So, we really can't fix this, since this restrictions are cgroup-bound, not process bound.

We should just document this (both on the DeviceAllow= documentation and on the Exec* documentation) and accept it.