-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should DevicePolicy affect execution of processes privileged using +? #26035
Comments
So as it turns out, we never consider |
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. |
DeviceAllow= and others are applied to the whole cgroup via bpf, so using '+' on an Exec line will not bypass them. Explain this in the manpage. Fixes systemd#26035
DeviceAllow= and others are applied to the whole cgroup via bpf, so using '+' on an Exec line will not bypass them. Explain this in the manpage. Fixes systemd#26035
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. |
DeviceAllow= and others are applied to the whole cgroup via bpf, so using '+' on an Exec line will not bypass them. Explain this in the manpage. Fixes systemd#26035
DeviceAllow= and others are applied to the whole cgroup via bpf, so using '+' on an Exec line will not bypass them. Explain this in the manpage. Fixes systemd#26035
DeviceAllow= and others are applied to the whole cgroup via bpf, so using '+' on an Exec line will not bypass them. Explain this in the manpage. Fixes #26035
DeviceAllow= and others are applied to the whole cgroup via bpf, so using '+' on an Exec line will not bypass them. Explain this in the manpage. Fixes systemd#26035
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:
Expectation vs reality:
-EPERM
on the open call. This works as expected./dev/autofs
. It works as expected.+
should disable sandboxing, so theDevicePolicy
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" (insystemd.service
). A number of directives (but notDevicePolicy
orDeviceAllow
) explain how+
is affected by them. That leaves the intended semantics a bit unclear. If this behavior is intended, I suggest extendingsystemd.resource-control
with a note explaining its interaction with+
.Additional program output to the terminal or log subsystem illustrating the issue
No response
The text was updated successfully, but these errors were encountered: