core: introduce new Delegate=yes/no property controlling creation of cgroup subhierarchies

For priviliged units this resource control property ensures that the
processes have all controllers systemd manages enabled.

For unpriviliged services (those with User= set) this ensures that
access rights to the service cgroup is granted to the user in question,
to create further subgroups. Note that this only applies to the
name=systemd hierarchy though, as access to other controllers is not
safe for unpriviliged processes.

Delegate=yes should be set for container scopes where a systemd instance
inside the container shall manage the hierarchies below its own cgroup
and have access to all controllers.

Delegate=yes should also be set for user@.service, so that systemd
--user can run, controlling its own cgroup tree.

This commit changes machined, systemd-nspawn@.service and user@.service
to set this boolean, in order to ensure that container management will
just work, and the user systemd instance can run fine.

1 files changed, 14 insertions, 0 deletions

diff --git a/man/systemd.resource-control.xml b/man/systemd.resource-control.xml
index 968b328dd9..218946d4ee 100644
--- a/man/systemd.resource-control.xml
+++ b/man/systemd.resource-control.xml
@@ -394,6 +394,20 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
         </listitem>
       </varlistentry>
 
+      <varlistentry>
+        <term><varname>Delegate=</varname></term>
+
+        <listitem>
+          <para>Turns on delegation of further resource control
+          partitioning to processes of the unit. For unpriviliged
+          services (i.e. those using the <varname>User=</varname>
+          setting) this allows processes to create a subhierarchy
+          beneath its control group path. For priviliged services and
+          scopes this ensures the processes will have all control
+          group controllers enabled.</para>
+        </listitem>
+      </varlistentry>
+
     </variablelist>
   </refsect1>