shaba/systemd-stable
1
1
Fork 0
mirror of https://github.com/systemd/systemd-stable.git synced 2024-12-23 17:34:00 +03:00
Code

Merge pull request #6735 from yuwata/multiple-capability-lines

Browse Source 
core: update man and test to support multiple CapabilityBoundingSet= lines
This commit is contained in:
Lennart Poettering 2017-09-04 15:36:30 +02:00 committed by GitHub
commit 89106f0a79
2 changed files with 22 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
man/systemd.exec.xml
View File

@ -925,11 +925,21 @@
inverted. Note that this option also affects the respective capabilities in the effective, permitted and
inheritable capability sets. If this option is not used, the capability bounding set is not modified on process
execution, hence no limits on the capabilities of the process are enforced. This option may appear more than
once, in which case the bounding sets are merged. If the empty string is assigned to this option, the bounding
set is reset to the empty capability set, and all prior settings have no effect. If set to
<literal>~</literal> (without any further argument), the bounding set is reset to the full set of available
once, in which case the bounding sets are merged by <constant>AND</constant>, or by <constant>OR</constant>
if the lines are prefixed with <literal>~</literal> (see below). If the empty string is assigned
to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect.
If set to <literal>~</literal> (without any further argument), the bounding set is reset to the full set of available
capabilities, also undoing any previous settings. This does not affect commands prefixed with
<literal>+</literal>.</para></listitem>
<literal>+</literal>.</para>
<para>Example: if a unit has the following,
<programlisting>CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=CAP_B CAP_C</programlisting>
then <constant>CAP_A</constant>, <constant>CAP_B</constant>, and <constant>CAP_C</constant> are set.
If the second line is prefixed with <literal>~</literal>, e.g.,
<programlisting>CapabilityBoundingSet=CAP_A CAP_B
CapabilityBoundingSet=~CAP_B CAP_C</programlisting>
then, only <constant>CAP_A</constant> is set.</para></listitem>
</varlistentry>
<varlistentry>
@ -938,7 +948,8 @@
<listitem><para>Controls which capabilities to include in the ambient capability set for the executed
process. Takes a whitespace-separated list of capability names, e.g. <constant>CAP_SYS_ADMIN</constant>,
<constant>CAP_DAC_OVERRIDE</constant>, <constant>CAP_SYS_PTRACE</constant>. This option may appear more than
once in which case the ambient capability sets are merged. If the list of capabilities is prefixed with
once in which case the ambient capability sets are merged (see the above examples in
<varname>CapabilityBoundingSet=</varname>). If the list of capabilities is prefixed with
<literal>~</literal>, all but the listed capabilities will be included, the effect of the assignment
inverted. If the empty string is assigned to this option, the ambient capability set is reset to the empty
capability set, and all prior settings have no effect. If set to <literal>~</literal> (without any further

6
src/test/test-unit-file.c
View File

@ -669,6 +669,12 @@ static void test_config_parse_capability_set(void) {
assert_se(r >= 0);
assert_se(capability_bounding_set == (make_cap(CAP_NET_RAW) | make_cap(CAP_NET_ADMIN)));
r = config_parse_capability_set(NULL, "fake", 1, "section", 1,
"CapabilityBoundingSet", 0, "~CAP_NET_ADMIN",
&capability_bounding_set, NULL);
assert_se(r >= 0);
assert_se(capability_bounding_set == make_cap(CAP_NET_RAW));
r = config_parse_capability_set(NULL, "fake", 1, "section", 1,
"CapabilityBoundingSet", 0, "",
&capability_bounding_set, NULL);