Skip to content

RFE: DynamicUser=yes breaks inside containers which block PID1 from setting up a mount namespace. Maybe allow a workaround, without having to modify the service? #10025

@sourcejedi

Description

@sourcejedi

systemd version the issue has been seen with
v239-713-g3457a7a93

Used distribution
Fedora 28

Expected behaviour you didn't see

Note, when you have a service with DynamicUser=yes, it uses a modified mount namespace. This is used to provide some assurance, that no file created with the dynamic UID will be accessible, if the UID is later re-used by a different service. http://0pointer.net/blog/dynamic-users-with-systemd.html

(Naturally, assurances not guaranteed if you have sufficient privileges, or the service unit includes BindPaths= :-).

But inside some types of container, the mount namespace features are not available. The assurances cannot be provided. Since poettering@1beab8b0d0ff2 , systemd chooses to fail the service in this case.

This RFE requests that we should be able to install a DynamicUser=yes service inside any container, and be able to have it work if we have pre-created the user. In that case the user is not dynamic, and so the mount namespace is not an essential requirement.

Unexpected behaviour you saw
Service with DynamicUser=yes fails when run inside container without CAP_SYS_ADMIN, even if the user has been pre-created.

Steps to reproduce the problem

1. Run a container without CAP_SYS_ADMIN:

systemd-nspawn -D fedora-28 -b --drop-cap=CAP_SYS_ADMIN

2. Pre-create the user for the service. I've just used the root user for this example.

3. Create a unit file like this:

# /etc/systemd/system/test.service
[Service]
DynamicUser=yes
User=root

ExecStart=/bin/true
Type=oneshot
RemainAfterExit=yes

Starting this service will fail. This RFE asserts that it could simply be allowed to succeed.

$ sudo systemctl start test
Job for test.service failed because the control process exited with error code.
See "systemctl status test.service" and "journalctl -xe" for details.
$ sudo systemctl status test
● test.service
   Loaded: loaded (/etc/systemd/system/test.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2018-09-06 12:32:26 BST; 17s ago
  Process: 91 ExecStart=/bin/true (code=exited, status=226/NAMESPACE)
 Main PID: 91 (code=exited, status=226/NAMESPACE)

Sep 06 12:32:26 fedora-28 systemd[1]: Starting test.service...
Sep 06 12:32:26 fedora-28 systemd[91]: test.service: Failed to set up mount namespacing: No anode
Sep 06 12:32:26 fedora-28 systemd[91]: test.service: Failed at step NAMESPACE spawning /bin/true: No anode
Sep 06 12:32:26 fedora-28 systemd[1]: test.service: Main process exited, code=exited, status=226/NAMESPACE
Sep 06 12:32:26 fedora-28 systemd[1]: test.service: Failed with result 'exit-code'.
Sep 06 12:32:26 fedora-28 systemd[1]: Failed to start test.service.

I think the above test case is what was meant by #10012 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFE 🎁Request for Enhancement, i.e. a feature requestpid1

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions