systemd DynamicUser=yes: what it turns on and what to watch

DynamicUser=yes makes systemd allocate a temporary user and group when a service starts and release them when it stops. It also switches on several protections at once. The main trap is files: anything the service leaves behind can be inherited by a later service that is given the same ID.

What it does

Per the systemd.exec manual, the user and group are not written to /etc/passwd or /etc/group. They exist only while the unit runs, and nss-systemd lets the rest of the system resolve them. The IDs come from the range 61184 to 65519, which the manual recommends keeping free of regular users.

If the name you give with User= already exists as a static account, that account is used and nothing dynamic is allocated.

What it implies

The manual lists these as turned on, and some cannot be turned off:

• NoNewPrivileges= and RestrictSUIDSGID=, so the process cannot gain privilege or create setuid and setgid files.
• ProtectSystem=strict and ProtectHome=read-only, so writes outside allowed locations fail.
• RemoveIPC=, which ties shared memory and similar objects to the service lifetime.
• A private temp area, using the disconnected form of PrivateTmp=, so the service cannot leave files in /tmp.

That is a lot of hardening for one line, which is why it suits small daemons that have no reason to own a fixed account.

The file ownership trap

IDs are recycled after a unit stops. The manual warns that if a service leaves files or directories owned by its dynamic user, a different unit might later get the same ID and gain access.

Handle it this way:

• Give the service a writable place through StateDirectory=, RuntimeDirectory= or LogsDirectory=, so systemd manages ownership and cleanup.
• Use ReadWritePaths= sparingly, and think about who owns what is created there.
• Do not point a dynamic service at a shared directory that outlives it unless you have thought through the ID reuse.

Checking what you got

After starting the unit, run systemctl show myservice -p User -p DynamicUser and ps -o user,pid,cmd -C myprogram to confirm which account the process actually uses. The temporary name usually matches the unit name, so it is easy to spot in process listings and in the journal.

When not to use it

Skip it if other tools need a stable user name, if files must be owned by a known account across restarts and shared with other services, or if a file level ACL is tied to a fixed ID. In those cases use a static system account and add the sandbox lines yourself, as in the basic five directives.

After you enable it, verify with the exposure score and check that the service still starts and writes where it should.

Safeguard covers the dependency side of the same service: SBOM and dependency scanning, with a free scan at gold.safeguard.sh/scan.

Quick check

Sources

• systemd.exec(5) manual page, man7.org, DynamicUser= section

Last reviewed: 19 October 2026.