From 6ef721cbc7dadee4ae878ecf0076d87e57233908 Mon Sep 17 00:00:00 2001 From: Luca Boccassi Date: Tue, 1 Nov 2022 23:34:15 +0000 Subject: user units: implicitly enable PrivateUsers= when sandboxing options are set Enabling these options when not running as root requires a user namespace, so implicitly enable PrivateUsers=. This has a side effect as it changes which users are visible to the unit. However until now these options did not work at all for user units, and in practice just a handful of user units in Fedora, Debian and Ubuntu mistakenly used them (and they have been all fixed since). This fixes the long-standing confusing issue that the user and system units take the same options but the behaviour is wildly (and sometimes silently) different depending on which is which, with user units requiring manually specifiying PrivateUsers= in order for sandboxing options to actually work and not be silently ignored. --- man/system-or-user-ns.xml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'man') diff --git a/man/system-or-user-ns.xml b/man/system-or-user-ns.xml index 7a302d5980..532c1ef64e 100644 --- a/man/system-or-user-ns.xml +++ b/man/system-or-user-ns.xml @@ -8,9 +8,13 @@ This option is only available for system services, or for services running in per-user - instances of the service manager when PrivateUsers= is enabled. + instances of the service manager in which case PrivateUsers= is implicitly enabled + (requires unprivileged user namespaces support to be enabled in the kernel via the + kernel.unprivileged_userns_clone= sysctl). These options are only available for system services, or for services running in per-user - instances of the service manager when PrivateUsers= is enabled. + instances of the service manager in which case PrivateUsers= is implicitly enabled + (requires unprivileged user namespaces support to be enabled in the kernel via the + kernel.unprivileged_userns_clone= sysctl). -- cgit v1.2.1