forked from pool/libvirt
72 lines
2.3 KiB
Diff
72 lines
2.3 KiB
Diff
|
From b6f1f5a3be5b2643b255882effdca2e903d9d738 Mon Sep 17 00:00:00 2001
|
||
|
From: =?UTF-8?q?C=C3=A9dric=20Bosdonnat?= <cbosdonnat@suse.com>
|
||
|
Date: Wed, 11 Jun 2014 17:01:11 +0200
|
||
|
Subject: [PATCH 3/3] lxc: update doc to mention features/capabilities/* domain
|
||
|
configuration
|
||
|
|
||
|
---
|
||
|
docs/drvlxc.html.in | 47 +++++++++++++++++++++++++++++++++++++++++++++++
|
||
|
1 file changed, 47 insertions(+)
|
||
|
|
||
|
diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in
|
||
|
index fc4bc20..403ce24 100644
|
||
|
--- a/docs/drvlxc.html.in
|
||
|
+++ b/docs/drvlxc.html.in
|
||
|
@@ -540,6 +540,53 @@ debootstrap, whatever) under /opt/vm-1-root:
|
||
|
</domain>
|
||
|
</pre>
|
||
|
|
||
|
+<h2><a name="capabilities">Altering the available capabilities</a></h2>
|
||
|
+
|
||
|
+<p>
|
||
|
+By default the libvirt LXC driver drops some capabilities among which CAP_MKNOD.
|
||
|
+However <span class="since">since 1.2.6</span> libvirt can be told to keep or
|
||
|
+drop some capabilities using a domain configuration like the following:
|
||
|
+</p>
|
||
|
+<pre>
|
||
|
+...
|
||
|
+<features>
|
||
|
+ <capabilities policy='default'>
|
||
|
+ <mknod state='on'/>
|
||
|
+ <sys_chroot state='off'/>
|
||
|
+ </capabilities>
|
||
|
+</features>
|
||
|
+...
|
||
|
+</pre>
|
||
|
+<p>
|
||
|
+The capabilities children elements are named after the capabilities as defined in
|
||
|
+<code>man 7 capabilities</code>. An <code>off</code> state tells libvirt to drop the
|
||
|
+capability, while an <code>on</code> state will force to keep the capability even though
|
||
|
+this one is dropped by default.
|
||
|
+</p>
|
||
|
+<p>
|
||
|
+The <code>policy</code> attribute can be one of <code>default</code>, <code>allow</code>
|
||
|
+or <code>deny</code>. It defines the default rules for capabilities: either keep the
|
||
|
+default behavior that is dropping a few selected capabilities, or keep all capabilities
|
||
|
+or drop all capabilities. The interest of <code>allow</code> and <code>deny</code> is that
|
||
|
+they guarantee that all capabilities will be kept (or removed) even if new ones are added
|
||
|
+later.
|
||
|
+</p>
|
||
|
+<p>
|
||
|
+The following example, drops all capabilities but CAP_MKNOD:
|
||
|
+</p>
|
||
|
+<pre>
|
||
|
+...
|
||
|
+<features>
|
||
|
+ <capabilities policy='deny'>
|
||
|
+ <mknod state='on'/>
|
||
|
+ </capabilities>
|
||
|
+</features>
|
||
|
+...
|
||
|
+</pre>
|
||
|
+<p>
|
||
|
+Note that allowing capabilities that are normally dropped by default can seriously
|
||
|
+affect the security of the container and the host.
|
||
|
+</p>
|
||
|
|
||
|
<h2><a name="usage">Container usage / management</a></h2>
|
||
|
|
||
|
--
|
||
|
1.8.4.5
|
||
|
|