</para>
<para>
- LXC has supports unprivileged containers. Unprivileged containers are
+ LXC has support for unprivileged containers. Unprivileged containers are
containers that are run without any privilege. This requires support for
user namespaces in the kernel that the container is run on. LXC was the
first runtime to support unprivileged containers after user namespaces
</para>
<para>
- LXC namespaces configuration keys by using single dots. This means complex
+ LXC namespaces configuration keys use single dots. This means complex
configuration keys such as <option>lxc.net.0</option> expose various
subkeys such as <option>lxc.net.0.type</option>,
<option>lxc.net.0.link</option>, <option>lxc.net.0.ipv6.address</option>, and
</term>
<listitem>
<para>
- Specify the proc file name to be set. The file name available
+ Specify the proc file name to be set. The file names available
are those listed under /proc/PID/.
Example:
</para>
<listitem>
<para>
The only allowed values are 0 and 1. Set this to 1 to destroy a
- container on shutdown.
+ container on shutdown.
</para>
</listitem>
</varlistentry>
network devices are usable in the container. It also
means that if both the container and host have upstart as
init, 'halt' in a container (for instance) will shut down the
- host.
+ host. Note that unprivileged containers do not work with this
+ setting due to an inability to mount sysfs. An unsafe workaround
+ would be to bind mount the host's sysfs.
</para>
<para>
the <option>lxc.net.[i].veth.pair</option> option (except for
unprivileged containers where this option is ignored for security
reasons).
+
+ Static routes can be added on the host pointing to the container using the
+ <option>lxc.net.[i].veth.ipv4.route</option> and
+ <option>lxc.net.[i].veth.ipv6.route</option> options.
+ Several lines specify several routes.
+ The route is in format x.y.z.t/m, eg. 192.168.1.0/24.
</para>
<para>
different macvlan on the same upper device. The accepted
modes are <option>private</option>, <option>vepa</option>,
<option>bridge</option> and <option>passthru</option>.
- In <option>private</option> mode, the device never
+ In <option>private</option> mode, the device never
communicates with any other device on the same upper_dev (default).
In <option>vepa</option> mode, the new Virtual Ethernet Port
Aggregator (VEPA) mode, it assumes that the adjacent
mode is possible for one physical interface.
</para>
+ <para>
+ <option>ipvlan:</option> an ipvlan interface is linked
+ with the interface specified by
+ the <option>lxc.net.[i].link</option> and assigned to
+ the container.
+ <option>lxc.net.[i].ipvlan.mode</option> specifies the
+ mode the ipvlan will use to communicate between
+ different ipvlan on the same upper device. The accepted
+ modes are <option>l3</option>, <option>l3s</option> and
+ <option>l2</option>. It defaults to <option>l3</option> mode.
+ In <option>l3</option> mode TX processing up to L3 happens on the stack instance
+ attached to the slave device and packets are switched to the stack instance of the
+ master device for the L2 processing and routing from that instance will be
+ used before packets are queued on the outbound device. In this mode the slaves
+ will not receive nor can send multicast / broadcast traffic.
+ In <option>l3s</option> mode TX processing is very similar to the L3 mode except that
+ iptables (conn-tracking) works in this mode and hence it is L3-symmetric (L3s).
+ This will have slightly less performance but that shouldn't matter since you are
+ choosing this mode over plain-L3 mode to make conn-tracking work.
+ In <option>l2</option> mode TX processing happens on the stack instance attached to
+ the slave device and packets are switched and queued to the master device to send
+ out. In this mode the slaves will RX/TX multicast and broadcast (if applicable) as well.
+ <option>lxc.net.[i].ipvlan.isolation</option> specifies the isolation mode.
+ The accepted isolation values are <option>bridge</option>,
+ <option>private</option> and <option>vepa</option>.
+ It defaults to <option>bridge</option>.
+ In <option>bridge</option> isolation mode slaves can cross-talk among themselves
+ apart from talking through the master device.
+ In <option>private</option> isolation mode the port is set in private mode.
+ i.e. port won't allow cross communication between slaves.
+ In <option>vepa</option> isolation mode the port is set in VEPA mode.
+ i.e. port will offload switching functionality to the external entity as
+ described in 802.1Qbg.
+ </para>
+
<para>
<option>phys:</option> an already existing interface
specified by the <option>lxc.net.[i].link</option> is
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>
+ <option>lxc.net.[i].l2proxy</option>
+ </term>
+ <listitem>
+ <para>
+ Controls whether layer 2 IP neighbour proxy entries will be added to the
+ lxc.net.[i].link interface for the IP addresses of the container.
+ Can be set to 0 or 1. Defaults to 0.
+ When used with IPv4 addresses, the following sysctl values need to be set:
+ net.ipv4.conf.[link].forwarding=1
+ When used with IPv6 addresses, the following sysctl values need to be set:
+ net.ipv6.conf.[link].proxy_ndp=1
+ net.ipv6.conf.[link].forwarding=1
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry>
<term>
<option>lxc.net.[i].mtu</option>
interface (as specified by the
<option>lxc.net.[i].link</option> option) and use that as
the gateway. <option>auto</option> is only available when
- using the <option>veth</option> and
- <option>macvlan</option> network types.
+ using the <option>veth</option>,
+ <option>macvlan</option> and <option>ipvlan</option> network types.
+ Can also have the special value of <option>dev</option>,
+ which means to set the default gateway as a device route.
+ This is primarily for use with layer 3 network modes, such as IPVLAN.
</para>
</listitem>
</varlistentry>
interface (as specified by the
<option>lxc.net.[i].link</option> option) and use that as
the gateway. <option>auto</option> is only available when
- using the <option>veth</option> and
- <option>macvlan</option> network types.
+ using the <option>veth</option>,
+ <option>macvlan</option> and <option>ipvlan</option> network types.
+ Can also have the special value of <option>dev</option>,
+ which means to set the default gateway as a device route.
+ This is primarily for use with layer 3 network modes, such as IPVLAN.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
LXC_NET_TYPE: the network type. This is one of the valid
- network types listed here (e.g. 'macvlan', 'veth').
+ network types listed here (e.g. 'vlan', 'macvlan', 'ipvlan', 'veth').
</para>
</listitem>
<listitem>
<para>
LXC_NET_TYPE: the network type. This is one of the valid
- network types listed here (e.g. 'macvlan', 'veth').
+ network types listed here (e.g. 'vlan', 'macvlan', 'ipvlan', 'veth').
</para>
</listitem>
When manually specifying a size for the log file the value should
be a power of 2 when converted to bytes. Valid size prefixes are
'KB', 'MB', 'GB'. (Note that all conversions are based on multiples
- of 1024. That means 'KB' == 'KiB', 'MB' == 'MiB', 'GB' == 'GiB'.
+ of 1024. That means 'KB' == 'KiB', 'MB' == 'MiB', 'GB' == 'GiB'.
Additionally, the case of the suffix is ignored, i.e. 'kB', 'KB' and
'Kb' are treated equally.)
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>
+ <option>lxc.rootfs.managed</option>
+ </term>
+ <listitem>
+ <para>
+ Set this to 0 to indicate that LXC is not managing the
+ container storage, then LXC will not modify the
+ container storage. The default is 1.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</refsect2>
<listitem>
<para>
Specify the control group value to be set on the unified cgroup
- shierarchy. The controller name is the literal name of the control
+ hierarchy. The controller name is the literal name of the control
group. The permitted names and the syntax of their values is not
dictated by LXC, instead it depends on the features of the Linux
kernel running at the time the container is started, eg.
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>
+ <option>lxc.cgroup.relative</option>
+ </term>
+ <listitem>
+ <para>
+ Set this to 1 to instruct LXC to never escape to the
+ root cgroup. This makes it easy for users to adhere to
+ restrictions enforced by cgroup2 and
+ systemd. Specifically, this makes it possible to run LXC
+ containers as systemd services.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</refsect2>
</para>
<para>
- To inherit the namespace from another container set the
+ To inherit the namespace from another container set the
<option>lxc.namespace.share.[namespace identifier]</option> to the name of
the container, e.g. <option>lxc.namespace.share.pid=c3</option>.
</para>
process wants to inherit the other's network namespace it usually
needs to inherit the user namespace as well.
</para>
+
+ <para>
+ Note that without careful additional configuration of an LSM,
+ sharing user+pid namespaces with a task may allow that task to
+ escalate privileges to that of the task calling liblxc.
+ </para>
</listitem>
</varlistentry>
</variablelist>
</term>
<listitem>
<para>
- Specify the kernel parameters to be set. The parameters available
+ Specify the kernel parameters to be set. The parameters available
are those listed under /proc/sys/.
Note that not all sysctls are namespaced. Changing Non-namespaced
sysctls will cause the system-wide setting to be modified.
<refentrytitle><command>sysctl</command></refentrytitle>
<manvolnum>8</manvolnum>
</citerefentry>.
- If used with no value, lxc will clear the parameters specified up
+ If used with no value, lxc will clear the parameters specified up
to this point.
</para>
</listitem>
container should be run can be specified in the container
configuration. The default is <command>lxc-container-default-cgns</command>
if the host kernel is cgroup namespace aware, or
- <command>lxc-container-default</command> othewise.
+ <command>lxc-container-default</command> otherwise.
</para>
<variablelist>
<varlistentry>
are nesting containers and are already confined), then use
</para>
<programlisting>lxc.apparmor.profile = unchanged</programlisting>
+ <para>
+ If you instruct LXC to generate the apparmor profile,
+ then use
+ </para>
+ <programlisting>lxc.apparmor.profile = generated</programlisting>
</listitem>
</varlistentry>
<varlistentry>
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>lxc.apparmor.allow_nesting</option>
+ </term>
+ <listitem>
+ <para>
+ If set this to 1, causes the following changes. When
+ generated apparmor profiles are used, they will contain
+ the necessary changes to allow creating a nested
+ container. In addition to the usual mount points,
+ <filename>/dev/.lxc/proc</filename>
+ and <filename>/dev/.lxc/sys</filename> will contain
+ procfs and sysfs mount points without the lxcfs
+ overlays, which, if generated apparmor profiles are
+ being used, will not be read/writable directly.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>lxc.apparmor.raw</option>
+ </term>
+ <listitem>
+ <para>
+ A list of raw AppArmor profile lines to append to the
+ profile. Only valid when using generated profiles.
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</refsect2>
Versions 1 and 2 are currently supported. In version 1, the
policy is a simple whitelist. The second line therefore must
read "whitelist", with the rest of the file containing one (numeric)
- sycall number per line. Each syscall number is whitelisted,
+ syscall number per line. Each syscall number is whitelisted,
while every unlisted number is blacklisted for use in the container
</para>
2
blacklist
mknod errno 0
+ ioctl notify
</programlisting>
+ <para>
+ Specifying "errno" as action will cause LXC to register a seccomp filter
+ that will cause a specific errno to be returned to the caller. The errno
+ value can be specified after the "errno" action word.
+ </para>
+
+ <para>
+ Specifying "notify" as action will cause LXC to register a seccomp
+ listener and retrieve a listener file descriptor from the kernel. When a
+ syscall is made that is registered as "notify" the kernel will generate a
+ poll event and send a message over the file descriptor. The caller can
+ read this message, inspect the syscalls including its arguments. Based on
+ this information the caller is expected to send back a message informing
+ the kernel which action to take. Until that message is sent the kernel
+ will block the calling process. The format of the messages to read and
+ sent is documented in seccomp itself.
+ </para>
+
<variablelist>
<varlistentry>
<term>
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>
+ <option>lxc.seccomp.allow_nesting</option>
+ </term>
+ <listitem>
+ <para>
+ If this flag is set to 1, then seccomp filters will be stacked
+ regardless of whether a seccomp profile is already loaded.
+ This allows nested containers to load their own seccomp profile.
+ The default setting is 0.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
+ <option>lxc.seccomp.notify.proxy</option>
+ </term>
+ <listitem>
+ <para>
+ Specify a unix socket to which LXC will connect and forward
+ seccomp events to. The path must by in the form
+ unix:/path/to/socket or unix:@socket. The former specifies a
+ path-bound unix domain socket while the latter specifies an
+ abstract unix domain socket.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</refsect2>
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>
+ <option>lxc.monitor.signal.pdeath</option>
+ </term>
+ <listitem>
+ <para>
+ Set the signal to be sent to the container's init when the lxc
+ monitor exits. By default it is set to SIGKILL which will cause
+ all container processes to be killed when the lxc monitor process
+ dies.
+ To ensure that containers stay alive even if lxc monitor dies set
+ this to 0.
+ </para>
+ </listitem>
+ </varlistentry>
<varlistentry>
<term>
<option>lxc.group</option>
projects / mirror_lxc.git / blobdiff