From: Zbigniew Jędrzejewski-Szmek Date: Sun, 3 Oct 2021 08:49:40 +0000 (+0200) Subject: man: add discussion of read-only filesystem support in daemons X-Git-Tag: v250-rc1~564 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e5f093bf99ed742b74b81ac97e0e5e01cde02d95;p=thirdparty%2Fsystemd.git man: add discussion of read-only filesystem support in daemons This is inspired by https://bugzilla.redhat.com/show_bug.cgi?id=1853293. Let's mention that applications should be prepared for /var being read-only. --- diff --git a/man/file-hierarchy.xml b/man/file-hierarchy.xml index 6c64b726f0f..3a24eca8cea 100644 --- a/man/file-hierarchy.xml +++ b/man/file-hierarchy.xml @@ -155,9 +155,8 @@ /run/ - A tmpfs file system for - system packages to place runtime data in. This directory is - flushed on boot, and generally writable for privileged + A tmpfs file system for system packages to place runtime data, + socket files, and similar. This directory is flushed on boot, and generally writable for privileged programs only. Always writable. @@ -288,17 +287,13 @@ /var/ - Persistent, variable system data. Must be - writable. This directory might be pre-populated with - vendor-supplied data, but applications should be able to - reconstruct necessary files and directories in this - subhierarchy should they be missing, as the system might start - up without this directory being populated. Persistency is - recommended, but optional, to support ephemeral systems. This - directory might become available or writable only very late - during boot. Components that are required to operate during - early boot hence shall not unconditionally rely on this - directory. + Persistent, variable system data. Writable during normal system operation. This + directory might be pre-populated with vendor-supplied data, but applications should be able to + reconstruct necessary files and directories in this subhierarchy should they be missing, as the + system might start up without this directory being populated. Persistency is recommended, but + optional, to support ephemeral systems. This directory might become available or writable only very + late during boot. Components that are required to operate during early boot hence shall not + unconditionally rely on this directory. @@ -560,48 +555,69 @@ - Unprivileged Write Access - - Unprivileged processes generally lack write access to most - of the hierarchy. - - The exceptions for normal users are - /tmp/, - /var/tmp/, - /dev/shm/, as well as the home directory - $HOME (usually found below - /home/) and the runtime directory - $XDG_RUNTIME_DIR (found below - /run/user/) of the user, which are all - writable. - - For unprivileged system processes, only - /tmp/, - /var/tmp/ and - /dev/shm/ are writable. If an - unprivileged system process needs a private writable directory in - /var/ or /run/, it is - recommended to either create it before dropping privileges in the - daemon code, to create it via - tmpfiles.d5 - fragments during boot, or via the - StateDirectory= and RuntimeDirectory= - directives of service units (see - systemd.unit5 - for details). - - /tmp/, /var/tmp/ and /dev/shm/ - should be mounted and , which means that set-user-id mode - and character or block special devices are not interpreted on those file systems. In general it is not - possible to mount them , because various programs use those directories for - dynamically generated or optimized code, and with that flag those use cases would break. Using this flag - is OK on special-purpose installations or systems where all software that may be installed is known and - doesn't require such functionality. See the discussion of - // in mount8 and - PROT_EXEC in mmap2. - + Write Access + + + Unprivileged Write Access + + Unprivileged processes generally lack write access to most of the hierarchy. + + The exceptions for normal users are + /tmp/, + /var/tmp/, + /dev/shm/, as well as the home directory + $HOME (usually found below + /home/) and the runtime directory + $XDG_RUNTIME_DIR (found below + /run/user/) of the user, which are all + writable. + + For unprivileged system processes, only + /tmp/, + /var/tmp/ and + /dev/shm/ are writable. If an + unprivileged system process needs a private writable directory in + /var/ or /run/, it is + recommended to either create it before dropping privileges in the + daemon code, to create it via + tmpfiles.d5 + fragments during boot, or via the + StateDirectory= and RuntimeDirectory= + directives of service units (see + systemd.unit5 + for details). + + /tmp/, /var/tmp/ and /dev/shm/ + should be mounted and , which means that set-user-id mode + and character or block special devices are not interpreted on those file systems. In general it is not + possible to mount them , because various programs use those directories for + dynamically generated or optimized code, and with that flag those use cases would break. Using this + flag is OK on special-purpose installations or systems where all software that may be installed is + known and doesn't require such functionality. See the discussion of + // in mount8 and + PROT_EXEC in mmap2. + + + + + Lack of Write Access on Read-Only Systems and during System Recovery + + As noted above, some systems operate with the /usr and + /etc hierarchies mounted read-only, possibly only allowing write access during + package upgrades. Other part of the hierarchy are generally mounted read-write (in particular + /var and /var/tmp), but may be read-only when the kernel + remounts the file system read-only in response to errors, or when the system is booted read-only for + recovery purposes. To the extent reasonable, applications should be prepared to execute without write + access, so that for example, failure to save non-essential data to /var/cache/ or + failure to create a custom log file under /var/log does not prevent the + application from running. + + The /run/ directory is available since the earliest boot and is always + writable. It should be used for any runtime data and sockets, so that write access to e.g. + /etc or /var is not needed. +