From e8f4bf33d8a6123ad8ae3955c989e36972f4884d Mon Sep 17 00:00:00 2001 From: dgcampea Date: Sat, 26 Jun 2021 13:23:20 +0100 Subject: [PATCH] man: fix incorrect description regarding DynamicUser= and StateDirectory= --- man/systemd.exec.xml | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index b17635c5d24..1789d97ce3f 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -1290,16 +1290,15 @@ CapabilityBoundingSet=~CAP_B CAP_C RootDirectory= or RootImage= these paths always reside on the host and are mounted from there into the unit's file system namespace. - If DynamicUser= is used in conjunction with - StateDirectory=, the logic for CacheDirectory= and - LogsDirectory= is slightly altered: the directories are created below - /var/lib/private, /var/cache/private and - /var/log/private, respectively, which are host directories made inaccessible to + If DynamicUser= is used, the logic for CacheDirectory=, + LogsDirectory= and StateDirectory= is slightly altered: the directories are created below + /var/cache/private, /var/log/private and /var/lib/private, + respectively, which are host directories made inaccessible to unprivileged users, which ensures that access to these directories cannot be gained through dynamic user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from perspective of the host and from inside the unit, the relevant directories hence always appear - directly below /var/lib, /var/cache and - /var/log. + directly below /var/cache, /var/log and + /var/lib. Use RuntimeDirectory= to manage one or more runtime directories for the unit and bind their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create -- 2.47.3