Linux Containers - LXC - Manpages - lxc.container.conf.5 (2024)

Man page of lxc.container.conf

Section: (5)
Updated: 2021-06-03
IndexReturn to Main Contents

NAME

lxc.container.conf - LXC container configuration file

DESCRIPTION

LXC is the well-known and heavily tested low-level Linux containerruntime. It is in active development since 2008 and has proven itself incritical production environments world-wide. Some of its core contributorsare the same people that helped to implement various well-knowncontainerization features inside the Linux kernel.

LXC's main focus is system containers. That is, containers which offer anenvironment as close as possible as the one you'd get from a VM butwithout the overhead that comes with running a separate kernel andsimulating all the hardware.

This is achieved through a combination of kernel security features such asnamespaces, mandatory access control and control groups.

LXC has support for unprivileged containers. Unprivileged containers arecontainers that are run without any privilege. This requires support foruser namespaces in the kernel that the container is run on. LXC was thefirst runtime to support unprivileged containers after user namespaceswere merged into the mainline kernel.

In essence, user namespaces isolate given sets of UIDs and GIDs. This isachieved by establishing a mapping between a range of UIDs and GIDs on thehost to a different (unprivileged) range of UIDs and GIDs in thecontainer. The kernel will translate this mapping in such a way thatinside the container all UIDs and GIDs appear as you would expect from thehost whereas on the host these UIDs and GIDs are in fact unprivileged. Forexample, a process running as UID and GID 0 inside the container mightappear as UID and GID 100000 on the host. The implementation and workingdetails can be gathered from the corresponding user namespace man page.UID and GID mappings can be defined with the lxc.idmapkey.

Linux containers are defined with a simple configuration file. Eachoption in the configuration file has the form key =value fitting in one line. The "#" character means the line is acomment. List options, like capabilities and cgroups options, can be usedwith no value to clear any previously defined values of that option.

LXC namespaces configuration keys use single dots. This means complexconfiguration keys such as lxc.net.0 expose varioussubkeys such as lxc.net.0.type,lxc.net.0.link, lxc.net.0.ipv6.address, andothers for even more fine-grained configuration.

CONFIGURATION

In order to ease administration of multiple related containers, it ispossible to have a container configuration file cause another file to beloaded. For instance, network configuration can be defined in one commonfile which is included by multiple containers. Then, if the containersare moved to another host, only one file may need to be updated.

lxc.include: Specify the file to be included. The included file must bein the same valid lxc configuration file format.

ARCHITECTURE

Allows one to set the architecture for the container. For example, set a32bits architecture for a container running 32bits binaries on a 64bitshost. This fixes the container scripts which rely on the architecture todo some work like downloading the packages.

lxc.arch: Specify the architecture for the container.
Some valid options arex86,i686,x86_64,amd64

HOSTNAME

The utsname section defines the hostname to be set for the container.That means the container can set its own hostname without changing theone from the system. That makes the hostname private for the container.

lxc.uts.name: specify the hostname for the container

HALT SIGNAL

Allows one to specify signal name or number sent to the container'sinit process to cleanly shutdown the container. Different init systemscould use different signals to perform clean shutdown sequence. Thisoption allows the signal to be specified in kill(1) fashion, e.g.SIGPWR, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signal isSIGPWR.

lxc.signal.halt: specify the signal used to halt the container

REBOOT SIGNAL

Allows one to specify signal name or number to reboot the container.This option allows signal to be specified in kill(1) fashion, e.g.SIGTERM, SIGRTMIN+14, SIGRTMAX-10 or plain number. The default signalis SIGINT.

lxc.signal.reboot: specify the signal used to reboot the container

STOP SIGNAL

Allows one to specify signal name or number to forcibly shutdown thecontainer. This option allows signal to be specified in kill(1) fashion,e.g. SIGKILL, SIGRTMIN+14, SIGRTMAX-10 or plain number. The defaultsignal is SIGKILL.

lxc.signal.stop: specify the signal used to stop the container

INIT COMMAND

Sets the command to use as the init system for the containers.

lxc.execute.cmd: Absolute path from container rootfs to the binary to run by default. Thismostly makes sense for lxc-execute.
lxc.init.cmd: Absolute path from container rootfs to the binary to use as init. Thismostly makes sense for lxc-start. Default is /sbin/init.

INIT WORKING DIRECTORY

Sets the absolute path inside the container as the working directory for the containers.LXC will switch to this directory before executing init.

lxc.init.cwd: Absolute path inside the container to use as the working directory.

INIT ID

Sets the UID/GID to use for the init system, and subsequent commands.Note that using a non-root UID when booting a system container willlikely not work due to missing privileges. Setting the UID/GID is mostlyuseful when running application containers.Defaults to: UID(0), GID(0)

lxc.init.uid: UID to use for init.
lxc.init.gid: GID to use for init.

PROC

Configure proc filesystem for the container.

lxc.proc.[proc file name]

Specify the proc file name to be set. The file names availableare those listed under /proc/PID/.Example:

 lxc.proc.oom_score_adj = 10

EPHEMERAL

Allows one to specify whether a container will be destroyed on shutdown.

lxc.ephemeral: The only allowed values are 0 and 1. Set this to 1 to destroy acontainer on shutdown.

NETWORK

The network section defines how the network is virtualized inthe container. The network virtualization acts at layertwo. In order to use the network virtualization, parametersmust be specified to define the network interfaces of thecontainer. Several virtual interfaces can be assigned and usedin a container even if the system has only one physicalnetwork interface.

lxc.net

may be used without a value to clear all previous network options.

lxc.net.[i].type

specify what kind of network virtualization to be usedfor the container.Must be specified before any other option(s) on the net device.Multiple networks can be specified by using an additional indexiafter all lxc.net.* keys. For example,lxc.net.0.type = veth andlxc.net.1.type = veth specify two differentnetworks of the same type. All keys sharing the same indexi will be treated as belonging to the samenetwork. For example, lxc.net.0.link = br0will belong to lxc.net.0.type.Currently, the different virtualization types can be:

none: will cause the container to sharethe host's network namespace. This means the hostnetwork devices are usable in the container. It alsomeans that if both the container and host have upstart asinit, 'halt' in a container (for instance) will shut down thehost. Note that unprivileged containers do not work with thissetting due to an inability to mount sysfs. An unsafe workaroundwould be to bind mount the host's sysfs.

empty: will create only the loopbackinterface.

veth: a virtual ethernet pairdevice is created with one side assigned to the containerand the other side on the host.lxc.net.[i].veth.mode specifies themode the veth parent will use on the host.The accepted modes are bridge and router.The mode defaults to bridge if not specified.In bridge mode the host side is attached to a bridge specified bythe lxc.net.[i].link option.If the bridge link is not specified, then the veth pair devicewill be created but not attached to any bridge.Otherwise, the bridge has to be created on the systembefore starting the container.lxc won't handle anyconfiguration outside of the container.In router mode static routes are created on the host for thecontainer's IP addresses pointing to the host side veth interface.Additionally Proxy ARP and Proxy NDP entries are added on the host side veth interfacefor the gateway IPs defined in the container to allow the container to reach the host.By default, lxc chooses a name for thenetwork device belonging to the outside of thecontainer, but if you wish to handlethis name yourselves, you can tell lxcto set a specific name withthe lxc.net.[i].veth.pair option (except forunprivileged containers where this option is ignored for securityreasons).Static routes can be added on the host pointing to the container using thelxc.net.[i].veth.ipv4.route andlxc.net.[i].veth.ipv6.route options.Several lines specify several routes.The route is in format x.y.z.t/m, eg. 192.168.1.0/24.In bridge mode untagged VLAN membership can be set with thelxc.net.[i].veth.vlan.id option. It accepts a special value of 'none' indicatingthat the container port should be removed from the bridge's default untagged VLAN.The lxc.net.[i].veth.vlan.tagged.id option can be specified multiple times to setthe container's bridge port membership to one or more tagged VLANs.

vlan: a vlan interface is linked withthe interface specified bythe lxc.net.[i].link and assigned tothe container. The vlan identifier is specified with theoption lxc.net.[i].vlan.id.

macvlan: a macvlan interface is linkedwith the interface specified bythe lxc.net.[i].link and assigned tothe container.lxc.net.[i].macvlan.mode specifies themode the macvlan will use to communicate betweendifferent macvlan on the same upper device. The acceptedmodes are private, vepa,bridge and passthru.In private mode, the device nevercommunicates with any other device on the same upper_dev (default).In vepa mode, the new Virtual Ethernet PortAggregator (VEPA) mode, it assumes that the adjacentbridge returns all frames where both source anddestination are local to the macvlan port, i.e. thebridge is set up as a reflective relay. Broadcastframes coming in from the upper_dev get flooded to allmacvlan interfaces in VEPA mode, local frames are notdelivered locally. In bridge mode, itprovides the behavior of a simple bridge betweendifferent macvlan interfaces on the same port. Framesfrom one interface to another one get delivered directlyand are not sent out externally. Broadcast frames getflooded to all other bridge ports and to the externalinterface, but when they come back from a reflectiverelay, we don't deliver them again. Since we know allthe MAC addresses, the macvlan bridge mode does notrequire learning or STP like the bridge module does. Inpassthru mode, all frames received bythe physical interface are forwarded to the macvlaninterface. Only one macvlan interface in passthrumode is possible for one physical interface.

NEW PSEUDO TTY INSTANCE (DEVPTS)

For stricter isolation the container can have its own privateinstance of the pseudo tty.

lxc.pty.max: If set, the container will have a new pseudo ttyinstance, making this private to it. The value specifiesthe maximum number of pseudo ttys allowed for a ptyinstance (this limitation is not implemented yet).

CONTAINER SYSTEM CONSOLE

If the container is configured with a root filesystem and theinittab file is setup to use the console, you may want to specifywhere the output of this console goes.

lxc.console.buffer.size: Setting this option instructs liblxc to allocate an in-memoryringbuffer. The container's console output will be written to theringbuffer. Note that ringbuffer must be at least as big as astandard page size. When passed a value smaller than a single pagesize liblxc will allocate a ringbuffer of a single page size. A pagesize is usually 4KB.The keyword 'auto' will cause liblxc to allocate a ringbuffer of128KB.When manually specifying a size for the ringbuffer the value shouldbe a power of 2 when converted to bytes. Valid size prefixes are'KB', 'MB', 'GB'. (Note that all conversions are based on multiplesof 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.)
lxc.console.size: Setting this option instructs liblxc to place a limit on the size ofthe console log file specified inlxc.console.logfile. Note that size of the log filemust be at least as big as a standard page size. When passed a valuesmaller than a single page size liblxc will set the size of log fileto a single page size. A page size is usually 4KB.The keyword 'auto' will cause liblxc to place a limit of 128KB onthe log file.When manually specifying a size for the log file the value shouldbe a power of 2 when converted to bytes. Valid size prefixes are'KB', 'MB', 'GB'. (Note that all conversions are based on multiplesof 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.)If users want to mirror the console ringbuffer on disk they should setlxc.console.size equal tolxc.console.buffer.size.
lxc.console.logfile: Specify a path to a file where the console output will be written.Note that in contrast to the on-disk ringbuffer logfile this filewill keep growing potentially filling up the users disks if notrotated and deleted. This problem can also be avoided by using thein-memory ringbuffer optionslxc.console.buffer.size andlxc.console.buffer.logfile.
lxc.console.rotate: Whether to rotate the console logfile specified inlxc.console.logfile. Users can send an APIrequest to rotate the logfile. Note that the old logfile will havethe same name as the original with the suffix ".1" appended.Users wishing to prevent the console log file from filling thedisk should rotate the logfile and delete it if unneeded. Thisproblem can also be avoided by using the in-memory ringbufferoptions lxc.console.buffer.size andlxc.console.buffer.logfile.
lxc.console.path: Specify a path to a device to which the console will beattached. The keyword 'none' will simply disable theconsole. Note, when specifying 'none' and creating a device nodefor the console in the container at /dev/console or bind-mountingthe hosts's /dev/console into the container at /dev/console thecontainer will have direct access to the hosts's /dev/console.This is dangerous when the container has write access to thedevice and should thus be used with caution.

CONSOLE THROUGH THE TTYS

This option is useful if the container is configured with a rootfilesystem and the inittab file is setup to launch a getty on thettys. The option specifies the number of ttys to be available forthe container. The number of gettys in the inittab file of thecontainer should not be greater than the number of ttys specifiedin this option, otherwise the excess getty sessions will die andrespawn indefinitely giving annoying messages on the console or in/var/log/messages.

lxc.tty.max: Specify the number of tty to make available to thecontainer.

CONSOLE DEVICES LOCATION

LXC consoles are provided through Unix98 PTYs created on thehost and bind-mounted over the expected devices in the container.By default, they are bind-mounted over /dev/consoleand /dev/ttyN. This can prevent package upgradesin the guest. Therefore you can specify a directory location (under/dev under which LXC will create the files andbind-mount over them. These will then be symbolically linked to/dev/console and /dev/ttyN.A package upgrade can then succeed as it is able to remove and replacethe symbolic links.

lxc.tty.dir: Specify a directory under /devunder which to create the container console devices. Note that LXCwill move any bind-mounts or device nodes for /dev/console intothis directory.

/DEV DIRECTORY

By default, lxc creates a few symbolic links (fd,stdin,stdout,stderr)in the container's /dev directory but does notautomatically create device node entries. This allows the container's/dev to be set up as needed in the containerrootfs. If lxc.autodev is set to 1, then after mounting the container'srootfs LXC will mount a fresh tmpfs under /dev(limited to 500K by default, unless defined in lxc.autodev.tmpfs.size)and fill in a minimal set of initial devices.This is generally required when starting a container containinga "systemd" based "init" but may be optional at other times. Additionaldevices in the containers /dev directory may be created through theuse of the lxc.hook.autodev hook.

lxc.autodev: Set this to 0 to stop LXC from mounting and populating a minimal/dev when starting the container.
lxc.autodev.tmpfs.size: Set this to define the size of the /dev tmpfs.The default value is 500000 (500K). If the parameter is usedbut without value, the default value is used.

MOUNT POINTS

The mount points section specifies the different places to bemounted. These mount points will be private to the containerand won't be visible by the processes running outside of thecontainer. This is useful to mount /etc, /var or /home forexamples.

NOTE - LXC will generally ensure that mount targets and relativebind-mount sources are properly confined under the containerroot, to avoid attacks involving over-mounting host directoriesand files. (Symbolic links in absolute mount sources are ignored)However, if the container configuration first mounts a directory whichis under the control of the container user, such as /home/joe, intothe container at some path, and then mountsunder path, then a TOCTTOU attack would bepossible where the container user modifies a symbolic link underhis home directory at just the right time.

lxc.mount.fstab

specify a file location inthe fstab format, containing themount information. The mount target location can and inmost cases should be a relative path, which will becomerelative to the mounted container root. For instance,

 proc proc proc nodev,noexec,nosuid 0 0

Will mount a proc filesystem under the container's /proc,regardless of where the root filesystem comes from. Thisis resilient to block device backed filesystems as well ascontainer cloning.

Note that when mounting a filesystem from animage file or block device the third field (fs_vfstype)cannot be auto as withmount(8)but must be explicitly specified.

lxc.mount.entry

Specify a mount point corresponding to a line in thefstab format.Moreover lxc supports mount propagation, such as rshared orrprivate, and adds three additional mount options.optional don't fail if mount does not work.create=dir or create=fileto create dir (or file) when the point will be mounted.relative source path is taken to be relative tothe mounted container root. For instance,

 dev/null proc/kcore none bind,relative 0 0

Will expand dev/null to ${LXC_ROOTFS_MOUNT}/dev/null,and mount it to proc/kcore inside the container.

lxc.mount.auto

specify which standard kernel file systems should beautomatically mounted. This may dramatically simplifythe configuration. The file systems are:

•: proc:mixed (or proc):mount /proc as read-write, butremount /proc/sys and/proc/sysrq-trigger read-onlyfor security / container isolation purposes.
•: proc:rw: mount/proc as read-write
•: sys:mixed (or sys):mount /sys as read-only but with/sys/devices/virtual/net writable.
•: sys:ro:mount /sys as read-onlyfor security / container isolation purposes.
•: sys:rw: mount/sys as read-write
•: cgroup:mixed:Mount a tmpfs to /sys/fs/cgroup,create directories for all hierarchies to which the containeris added, create subdirectories in those hierarchies with thename of the cgroup, and bind-mount the container's own cgroupinto that directory. The container will be able to write toits own cgroup directory, but not the parents, since they willbe remounted read-only.
•: cgroup:mixed:force:The force option will cause LXC to performthe cgroup mounts for the container under all circ*mstances.Otherwise it is similar to cgroup:mixed.This is mainly useful when the cgroup namespaces are enabledwhere LXC will normally leave mounting cgroups to the initbinary of the container since it is perfectly safe to do so.
•: cgroup:ro:similar to cgroup:mixed, but everything willbe mounted read-only.
•: cgroup:ro:force:The force option will cause LXC to performthe cgroup mounts for the container under all circ*mstances.Otherwise it is similar to cgroup:ro.This is mainly useful when the cgroup namespaces are enabledwhere LXC will normally leave mounting cgroups to the initbinary of the container since it is perfectly safe to do so.
•: cgroup:rw: similar tocgroup:mixed, but everything will be mountedread-write. Note that the paths leading up to the container'sown cgroup will be writable, but will not be a cgroupfilesystem but just part of the tmpfs of/sys/fs/cgroup
•: cgroup:rw:force:The force option will cause LXC to performthe cgroup mounts for the container under all circ*mstances.Otherwise it is similar to cgroup:rw.This is mainly useful when the cgroup namespaces are enabledwhere LXC will normally leave mounting cgroups to the initbinary of the container since it is perfectly safe to do so.
•: cgroup (without specifier):defaults to cgroup:rw if thecontainer retains the CAP_SYS_ADMIN capability,cgroup:mixed otherwise.
•: cgroup-full:mixed:mount a tmpfs to /sys/fs/cgroup,create directories for all hierarchies to whichthe container is added, bind-mount the hierarchiesfrom the host to the container and make everythingread-only except the container's own cgroup. Notethat compared to cgroup, whereall paths leading up to the container's own cgroupare just simple directories in the underlyingtmpfs, here/sys/fs/cgroup/$hierarchywill contain the host's full cgroup hierarchy,albeit read-only outside the container's own cgroup.This may leak quite a bit of information into thecontainer.
•: cgroup-full:mixed:force:The force option will cause LXC to performthe cgroup mounts for the container under all circ*mstances.Otherwise it is similar to cgroup-full:mixed.This is mainly useful when the cgroup namespaces are enabledwhere LXC will normally leave mounting cgroups to the initbinary of the container since it is perfectly safe to do so.
•: cgroup-full:ro: similar tocgroup-full:mixed, but everythingwill be mounted read-only.
•: cgroup-full:ro:force:The force option will cause LXC to performthe cgroup mounts for the container under all circ*mstances.Otherwise it is similar to cgroup-full:ro.This is mainly useful when the cgroup namespaces are enabledwhere LXC will normally leave mounting cgroups to the initbinary of the container since it is perfectly safe to do so.
•: cgroup-full:rw: similar tocgroup-full:mixed, but everythingwill be mounted read-write. Note that in this case,the container may escape its own cgroup. (Note alsothat if the container has CAP_SYS_ADMIN supportand can mount the cgroup filesystem itself, it maydo so anyway.)
•: cgroup-full:rw:force:The force option will cause LXC to performthe cgroup mounts for the container under all circ*mstances.Otherwise it is similar to cgroup-full:rw.This is mainly useful when the cgroup namespaces are enabledwhere LXC will normally leave mounting cgroups to the initbinary of the container since it is perfectly safe to do so.
•: cgroup-full (without specifier):defaults to cgroup-full:rw if thecontainer retains the CAP_SYS_ADMIN capability,cgroup-full:mixed otherwise.

If cgroup namespaces are enabled, then any cgroupauto-mounting request will be ignored, since the container canmount the filesystems itself, and automounting can confuse thecontainer init.

Note that if automatic mounting of the cgroup filesystemis enabled, the tmpfs under/sys/fs/cgroup will always bemounted read-write (but for the :mixedand :ro cases, the individualhierarchies,/sys/fs/cgroup/$hierarchy, will beread-only). This is in order to work around a quirk inUbuntu'smountall(8)command that will cause containers to wait for userinput at boot if/sys/fs/cgroup is mounted read-onlyand the container can't remount it read-write due to alack of CAP_SYS_ADMIN.

Examples:

 lxc.mount.auto = proc sys cgroup lxc.mount.auto = proc:rw sys:rw cgroup-full:rw

ROOT FILE SYSTEM

The root file system of the container can be different than thatof the host system.

lxc.rootfs.path: specify the root file system for the container. It canbe an image file, a directory or a block device. If notspecified, the container shares its root file systemwith the host.
For directory or simple block-device backed containers,a pathname can be used. If the rootfs is backed by a nbddevice, then nbd:file:1 specifies thatfile should be attached to a nbd device,and partition 1 should be mounted as the rootfs.nbd:file specifies that the nbd deviceitself should be mounted. overlayfs:/lower:/upperspecifies that the rootfs should be an overlay with /upperbeing mounted read-write over a read-only mount of /lower.For overlay multiple /lowerdirectories can be specified. loop:/file tells lxc to attach/file to a loop device and mount the loop device.
lxc.rootfs.mount: where to recursively bind lxc.rootfs.pathbefore pivoting. This is to ensure success of thepivot_root(8)syscall. Any directory suffices, the default shouldgenerally work.
lxc.rootfs.options: Specify extra mount options to use when mounting the rootfs.The format of the mount options corresponds to theformat used in fstab. In addition, LXC supports the customidmap= mount option. This option can be usedto tell LXC to create an idmapped mount for the container'srootfs. This is useful when the user doesn't want to recursivelychown the rootfs of the container to match the idmapping of theuser namespace the container is going to use. Instead anidmapped mount can be used to handle this.The argument foridmap=can either be a path pointing to a user namespace file thatLXC will open and use to idmap the rootfs or the special value"container" which will instruct LXC to usethe container's user namespace to idmap the rootfs.
lxc.rootfs.managed: Set this to 0 to indicate that LXC is not managing thecontainer storage, then LXC will not modify thecontainer storage. The default is 1.

CONTROL GROUPS ("CGROUPS")

The control group section contains the configuration for thedifferent subsystem. lxc does not check thecorrectness of the subsystem name. This has the disadvantageof not detecting configuration errors until the container isstarted, but has the advantage of permitting any futuresubsystem.

The kernel implementation of cgroups has changed significantly over theyears. With Linux 4.5 support for a new cgroup filesystem was addedusually referred to as "cgroup2" or "unified hierarchy". Since then theold cgroup filesystem is usually referred to as "cgroup1" or the"legacy hierarchies". Please see the cgroups manual page for a detailedexplanation of the differences between the two versions.

LXC distinguishes settings for the legacy and the unified hierarchy byusing different configuration key prefixes. To alter settings forcontrollers in a legacy hierarchy the key prefixlxc.cgroup. must be used and in order to alter thesettings for a controller in the unified hierarchy thelxc.cgroup2. key must be used. Note that LXC willignore lxc.cgroup. settings on systems that only usethe unified hierarchy. Conversely, it will ignorelxc.cgroup2. options on systems that only use legacyhierachies.

At its core a cgroup hierarchy is a way to hierarchically organizeprocesses. Usually a cgroup hierarchy will have one or more"controllers" enabled. A "controller" in a cgroup hierarchy is usuallyresponsible for distributing a specific type of system resource alongthe hierarchy. Controllers include the "pids" controller, the "cpu"controller, the "memory" controller and others. Some controllershowever do not fall into the category of distributing a systemresource, instead they are often referred to as "utility" controllers.One utility controller is the device controller. Instead ofdistributing a system resource it allows to manage device access.

In the legacy hierarchy the device controller was implemented like mostother controllers as a set of files that could be written to. Thesefiles where named "devices.allow" and "devices.deny". The legacy devicecontroller allowed the implementation of both "allowlists" and"denylists".

An allowlist is a device program that by default blocks access to alldevices. In order to access specific devices "allow rules" forparticular devices or device classes must be specified. In contrast, adenylist is a device program that by default allows access to alldevices. In order to restrict access to specific devices "deny rules"for particular devices or device classes must be specified.

In the unified cgroup hierarchy the implementation of the devicecontroller has completely changed. Instead of files to read from andwrite to a eBPF program ofBPF_PROG_TYPE_CGROUP_DEVICE can be attached to acgroup. Even though the kernel implementation has changed completelyLXC tries to allow for the same semantics to be followed in the legacydevice cgroup and the unified eBPF-based device controller. Thefollowing paragraphs explain the semantics for the unified eBPF-baseddevice controller.

CAPABILITIES

The capabilities can be dropped in the container if this oneis run as root.

lxc.cap.drop: Specify the capability to be dropped in the container. Asingle line defining several capabilities with a spaceseparation is allowed. The format is the lower case ofthe capability definition without the "CAP_" prefix,eg. CAP_SYS_MODULE should be specified assys_module. Seecapabilities(7).If used with no value, lxc will clear any drop capabilitiesspecified up to this point.
lxc.cap.keep: Specify the capability to be kept in the container. All othercapabilities will be dropped. When a special value of "none" isencountered, lxc will clear any keep capabilities specified upto this point. A value of "none" alone can be used to drop allcapabilities.

NAMESPACES

A namespace can be cloned (lxc.namespace.clone),kept (lxc.namespace.keep) or shared(lxc.namespace.share.[namespace identifier]).

lxc.namespace.clone

Specify namespaces which the container is supposed to be createdwith. The namespaces to create are specified as a space separatedlist. Each namespace must correspond to one of the standardnamespace identifiers as seen in the/proc/PID/ns directory.When lxc.namespace.clone is not explicitly set allnamespaces supported by the kernel and the current configurationwill be used.

To create a new mount, net and ipc namespace setlxc.namespace.clone=mount net ipc.

lxc.namespace.keep

Specify namespaces which the container is supposed to inherit fromthe process that created it. The namespaces to keep are specified asa space separated list. Each namespace must correspond to one of thestandard namespace identifiers as seen in the/proc/PID/ns directory.The lxc.namespace.keep is adenylist option, i.e. it is useful when enforcing that containersmust keep a specific set of namespaces.

To keep the network, user and ipc namespace setlxc.namespace.keep=user net ipc.

Note that sharing pid namespaces will likely not work with most initsystems.

Note that if the container requests a new user namespace and thecontainer wants to inherit the network namespace it needs to inheritthe user namespace as well.

lxc.namespace.share.[namespace identifier]

Specify a namespace to inherit from another container or process.The [namespace identifier] suffix needs to bereplaced with one of the namespaces that appear in the/proc/PID/ns directory.

To inherit the namespace from another process set thelxc.namespace.share.[namespace identifier] to the PID ofthe process, e.g. lxc.namespace.share.net=42.

To inherit the namespace from another container set thelxc.namespace.share.[namespace identifier] to the name ofthe container, e.g. lxc.namespace.share.pid=c3.

To inherit the namespace from another container located in adifferent path than the standard liblxc path set thelxc.namespace.share.[namespace identifier] to the fullpath to the container, e.g.lxc.namespace.share.user=/opt/c3.

In order to inherit namespaces the caller needs to have sufficientprivilege over the process or container.

Note that sharing pid namespaces between system containers willlikely not work with most init systems.

Note that if two processes are in different user namespaces and oneprocess wants to inherit the other's network namespace it usuallyneeds to inherit the user namespace as well.

Note that without careful additional configuration of an LSM,sharing user+pid namespaces with a task may allow that task toescalate privileges to that of the task calling liblxc.

lxc.time.offset.boot

Specify a positive or negative offset for the boottime clock. Theformat accepts hours (h), minutes (m), seconds (s),milliseconds (ms), microseconds (us), and nanoseconds (ns).

lxc.time.offset.monotonic

Specify a positive or negative offset for the monotonic clock. Theformat accepts hours (h), minutes (m), seconds (s),milliseconds (ms), microseconds (us), and nanoseconds (ns).

RESOURCE LIMITS

The soft and hard resource limits for the container can be changed.Unprivileged containers can only lower them. Resources which are notexplicitly specified will be inherited.

lxc.prlimit.[limit name]: Specify the resource limit to be set. A limit is specified as twocolon separated values which are either numeric or the word'unlimited'. A single value can be used as a shortcut to set bothsoft and hard limit to the same value. The permitted names the"RLIMIT_" resource names in lowercase without the "RLIMIT_"prefix, eg. RLIMIT_NOFILE should be specified as "nofile". Seesetrlimit(2).If used with no value, lxc will clear the resource limitspecified up to this point. A resource with no explicitlyconfigured limitation will be inherited from the process startingup the container.

SYSCTL

Configure kernel parameters for the container.

lxc.sysctl.[kernel parameters name]: Specify the kernel parameters to be set. The parameters availableare those listed under /proc/sys/.Note that not all sysctls are namespaced. Changing Non-namespacedsysctls will cause the system-wide setting to be modified.sysctl(8).If used with no value, lxc will clear the parameters specified upto this point.

APPARMOR PROFILE

If lxc was compiled and installed with apparmor support, and the hostsystem has apparmor enabled, then the apparmor profile under which thecontainer should be run can be specified in the containerconfiguration. The default is lxc-container-default-cgnsif the host kernel is cgroup namespace aware, orlxc-container-default otherwise.

lxc.apparmor.profile

Specify the apparmor profile under which the container shouldbe run. To specify that the container should be unconfined,use

lxc.apparmor.profile = unconfined

If the apparmor profile should remain unchanged (i.e. if youare nesting containers and are already confined), then use

lxc.apparmor.profile = unchanged

If you instruct LXC to generate the apparmor profile,then use

lxc.apparmor.profile = generated

lxc.apparmor.allow_incomplete

Apparmor profiles are pathname based. Therefore many filerestrictions require mount restrictions to be effective againsta determined attacker. However, these mount restrictions are notyet implemented in the upstream kernel. Without the mountrestrictions, the apparmor profiles still protect against accidentaldamager.

If this flag is 0 (default), then the container will not bestarted if the kernel lacks the apparmor mount features, so that aregression after a kernel upgrade will be detected. To start thecontainer under partial apparmor protection, set this flag to 1.

lxc.apparmor.allow_nesting

If set this to 1, causes the following changes. Whengenerated apparmor profiles are used, they will containthe necessary changes to allow creating a nestedcontainer. In addition to the usual mount points,/dev/.lxc/procand /dev/.lxc/sys will containprocfs and sysfs mount points without the lxcfsoverlays, which, if generated apparmor profiles arebeing used, will not be read/writable directly.

lxc.apparmor.raw

A list of raw AppArmor profile lines to append to theprofile. Only valid when using generated profiles.

SELINUX CONTEXT

If lxc was compiled and installed with SELinux support, and the hostsystem has SELinux enabled, then the SELinux context under which thecontainer should be run can be specified in the containerconfiguration. The default is unconfined_t,which means that lxc will not attempt to change contexts.See /usr/share/lxc/selinux/lxc.te for an example policy and moreinformation.

lxc.selinux.context

Specify the SELinux context under which the container shouldbe run or unconfined_t. For example

lxc.selinux.context = system_u:system_r:lxc_t:s0:c22

lxc.selinux.context.keyring

Specify the SELinux context under which the container's keyringshould be created. By default this the same as lxc.selinux.context, orthe context lxc is executed under if lxc.selinux.context has not been set.

lxc.selinux.context.keyring = system_u:system_r:lxc_t:s0:c22

KERNEL KEYRING

The Linux Keyring facility is primarily a way for variouskernel components to retain or cache security data, authenticationkeys, encryption keys, and other data in the kernel. By default lxcwill create a new session keyring for the started application.

lxc.keyring.session

Disable the creation of new session keyring by lxc. The startedapplication will then inherit the current session keyring.By default, or when passing the value 1, a new keyring will be created.

lxc.keyring.session = 0

SECCOMP CONFIGURATION

A container can be started with a reduced set of availablesystem calls by loading a seccomp profile at startup. Theseccomp configuration file must begin with a version numberon the first line, a policy type on the second line, followedby the configuration.

Versions 1 and 2 are currently supported. In version 1, thepolicy is a simple allowlist. The second line therefore mustread "allowlist", with the rest of the file containing one (numeric)syscall number per line. Each syscall number is allowlisted,while every unlisted number is denylisted for use in the container

In version 2, the policy may be denylist or allowlist,supports per-rule and per-policy default actions, and supportsper-architecture system call resolution from textual names.

An example denylist policy, in which all system calls areallowed except for mknod, which will simply do nothing andreturn 0 (success), looks like:

 2 denylist mknod errno 0 ioctl notify

Specifying "errno" as action will cause LXC to register a seccomp filterthat will cause a specific errno to be returned to the caller. The errnovalue can be specified after the "errno" action word.

Specifying "notify" as action will cause LXC to register a seccomplistener and retrieve a listener file descriptor from the kernel. When asyscall is made that is registered as "notify" the kernel will generate apoll event and send a message over the file descriptor. The caller canread this message, inspect the syscalls including its arguments. Based onthis information the caller is expected to send back a message informingthe kernel which action to take. Until that message is sent the kernelwill block the calling process. The format of the messages to read andsent is documented in seccomp itself.

lxc.seccomp.profile: Specify a file containing the seccomp configuration toload before the container starts.
lxc.seccomp.allow_nesting: If this flag is set to 1, then seccomp filters will be stackedregardless of whether a seccomp profile is already loaded.This allows nested containers to load their own seccomp profile.The default setting is 0.
lxc.seccomp.notify.proxy: Specify a unix socket to which LXC will connect and forwardseccomp events to. The path must be in the formunix:/path/to/socket or unix:@socket. The former specifies apath-bound unix domain socket while the latter specifies anabstract unix domain socket.
lxc.seccomp.notify.cookie: An additional string sent along with proxied seccomp notificationrequests.

PR_SET_NO_NEW_PRIVS

With PR_SET_NO_NEW_PRIVS active execve() promises not to grantprivileges to do anything that could not have been done withoutthe execve() call (for example, rendering the set-user-ID andset-group-ID mode bits, and file capabilities non-functional).Once set, this bit cannot be unset. The setting of this bit isinherited by children created by fork() and clone(), and preservedacross execve().Note that PR_SET_NO_NEW_PRIVS is applied after the container haschanged into its intended AppArmor profile or SElinux context.

lxc.no_new_privs: Specify whether the PR_SET_NO_NEW_PRIVS flag should be set for thecontainer. Set to 1 to activate.

UID MAPPINGS

A container can be started in a private user namespace withuser and group id mappings. For instance, you can map userid0 in the container to userid 200000 on the host. The rootuser in the container will be privileged in the container,but unprivileged on the host. Normally a system containerwill want a range of ids, so you would map, for instance,user and group ids 0 through 20,000 in the container to theids 200,000 through 220,000.

lxc.idmap: Four values must be provided. First a character, either'u', or 'g', to specify whether user or group ids arebeing mapped. Next is the first userid as seen in theuser namespace of the container. Next is the userid asseen on the host. Finally, a range indicating the numberof consecutive ids to map.

CONTAINER HOOKS

Container hooks are programs or scripts which can be executedat various times in a container's lifetime.

When a container hook is executed, additional information is passedalong. The lxc.hook.version argument can be used todetermine if the following arguments are passed as command linearguments or through environment variables. The arguments are:

•: Container name.
•: Section (always 'lxc').
•: The hook type (i.e. 'clone' or 'pre-mount').
•: Additional arguments. In thecase of the clone hook, any extra arguments passed will appear asfurther arguments to the hook. In the case of the stop hook, paths tofiledescriptors for each of the container's namespaces along withtheir types are passed.

The following environment variables are set:

•: LXC_CGNS_AWARE: indicator whether the container iscgroup namespace aware.
•: LXC_CONFIG_FILE: the path to the containerconfiguration file.
•: LXC_HOOK_TYPE: the hook type (e.g. 'clone', 'mount','pre-mount'). Note that the existence of this environment variable isconditional on the value of lxc.hook.version. If itis set to 1 then LXC_HOOK_TYPE will be set.
•: LXC_HOOK_SECTION: the section type (e.g. 'lxc','net'). Note that the existence of this environment variable isconditional on the value of lxc.hook.version. If itis set to 1 then LXC_HOOK_SECTION will be set.
•: LXC_HOOK_VERSION: the version of the hooks. Thisvalue is identical to the value of the container'slxc.hook.version config item. If it is set to 0 thenold-style hooks are used. If it is set to 1 then new-style hooks areused.
•: LXC_LOG_LEVEL: the container's log level.
•: LXC_NAME: is the container's name.
•: LXC_[NAMESPACE IDENTIFIER]_NS: path under/proc/PID/fd/ to a file descriptor referring to the container'snamespace. For each preserved namespace type there will be a separateenvironment variable. These environment variables will only be set iflxc.hook.version is set to 1.
•: LXC_ROOTFS_MOUNT: the path to the mounted root filesystem.
•: LXC_ROOTFS_PATH: this is the lxc.rootfs.path entryfor the container. Note this is likely not where the mounted rootfs isto be found, use LXC_ROOTFS_MOUNT for that.
•: LXC_SRC_NAME: in the case of the clone hook, this isthe original container's name.

Standard output from the hooks is logged at debug level.Standard error is not logged, but can be captured by thehook redirecting its standard error to standard output.

lxc.hook.version: To pass the arguments in new style via environment variables set to1 otherwise set to 0 to pass them as arguments.This setting affects all hooks arguments that were traditionallypassed as arguments to the script. Specifically, it affects thecontainer name, section (e.g. 'lxc', 'net') and hook type (e.g.'clone', 'mount', 'pre-mount') arguments. If new-style hooks areused then the arguments will be available as environment variables.The container name will be set in LXC_NAME. (This is setindependently of the value used for this config item.) The sectionwill be set in LXC_HOOK_SECTION and the hook type will be set inLXC_HOOK_TYPE.It also affects how the paths to file descriptors referring to thecontainer's namespaces are passed. If set to 1 then for eachnamespace a separate environment variable LXC_[NAMESPACEIDENTIFIER]_NS will be set. If set to 0 then the paths will bepassed as arguments to the stop hook.
lxc.hook.pre-start: A hook to be run in the host's namespace before thecontainer ttys, consoles, or mounts are up.
lxc.hook.pre-mount: A hook to be run in the container's fs namespace but beforethe rootfs has been set up. This allows for manipulationof the rootfs, i.e. to mount an encrypted filesystem. Mountsdone in this hook will not be reflected on the host (apart frommounts propagation), so they will be automatically cleaned upwhen the container shuts down.
lxc.hook.mount: A hook to be run in the container's namespace aftermounting has been done, but before the pivot_root.
lxc.hook.autodev: A hook to be run in the container's namespace aftermounting has been done and after any mount hooks haverun, but before the pivot_root, iflxc.autodev == 1.The purpose of this hook is to assist in populating the/dev directory of the container when using the autodevoption for systemd based containers. The container's /devdirectory is relative to the${LXC_ROOTFS_MOUNT} environmentvariable available when the hook is run.
lxc.hook.start-host: A hook to be run in the host's namespace after thecontainer has been setup, and immediately before startingthe container init.
lxc.hook.start: A hook to be run in the container's namespace immediatelybefore executing the container's init. This requires theprogram to be available in the container.
lxc.hook.stop: A hook to be run in the host's namespace with referencesto the container's namespaces after the container has been shutdown. For each namespace an extra argument is passed to the hookcontaining the namespace's type and a filename that can be used toobtain a file descriptor to the corresponding namespace, separatedby a colon. The type is the name as it would appear in the/proc/PID/ns directory.For instance for the mount namespace the argument usually lookslike mnt:/proc/PID/fd/12.
lxc.hook.post-stop: A hook to be run in the host's namespace after thecontainer has been shut down.
lxc.hook.clone: A hook to be run when the container is cloned to a new one.See lxc-clone(1) for more information.
lxc.hook.destroy: A hook to be run when the container is destroyed.

CONTAINER HOOKS ENVIRONMENT VARIABLES

A number of environment variables are made available to the startuphooks to provide configuration information and assist in thefunctioning of the hooks. Not all variables are valid in allcontexts. In particular, all paths are relative to the host systemand, as such, not valid during the lxc.hook.start hook.

LXC_NAME: The LXC name of the container. Useful for logging messagesin common log environments. [-n]
LXC_CONFIG_FILE: Host relative path to the container configuration file. Thisgives the container to reference the original, top level,configuration file for the container in order to locate anyadditional configuration information not otherwise madeavailable. [-f]
LXC_CONSOLE: The path to the console output of the container if not NULL.[-c] [lxc.console.path]
LXC_CONSOLE_LOGPATH: The path to the console log output of the container if not NULL.[-L]
LXC_ROOTFS_MOUNT: The mount location to which the container is initially bound.This will be the host relative path to the container rootfsfor the container instance being started and is where changesshould be made for that instance.[lxc.rootfs.mount]
LXC_ROOTFS_PATH: The host relative path to the container root which has beenmounted to the rootfs.mount location.[lxc.rootfs.path]
LXC_SRC_NAME: Only for the clone hook. Is set to the original container name.
LXC_TARGET: Only for the stop hook. Is set to "stop" for a containershutdown or "reboot" for a container reboot.
LXC_CGNS_AWARE: If unset, then this version of lxc is not aware of cgroupnamespaces. If set, it will be set to 1, and lxc is awareof cgroup namespaces. Note this does not guarantee thatcgroup namespaces are enabled in the kernel. This is usedby the lxcfs mount hook.

LOGGING

Logging can be configured on a per-container basis. By default,depending upon how the lxc package was compiled, container startupis logged only at the ERROR level, and logged to a file named afterthe container (with '.log' appended) either under the container path,or under /var/log/lxc.

Both the default log level and the log file can be specified in thecontainer configuration file, overriding the default behavior. Notethat the configuration file entries can in turn be overridden by thecommand line options to lxc-start.

lxc.log.level: The level at which to log. The log level is an integer inthe range of 0..8 inclusive, where a lower number means moreverbose debugging. In particular 0 = trace, 1 = debug, 2 =info, 3 = notice, 4 = warn, 5 = error, 6 = critical, 7 =alert, and 8 = fatal. If unspecified, the level defaultsto 5 (error), so that only errors and above are logged.
Note that when a script (such as either a hook script or anetwork interface up or down script) is called, the script'sstandard output is logged at level 1, debug.
lxc.log.file: The file to which logging info should be written.
lxc.log.syslog: Send logging info to syslog. It respects the log level defined inlxc.log.level. The argument should be the syslogfacility to use, valid ones are: daemon, local0, local1, local2,local3, local4, local5, local5, local6, local7.

AUTOSTART

The autostart options support marking which containers should beauto-started and in what order. These options may be used by LXC toolsdirectly or by external tooling provided by the distributions.

lxc.start.auto: Whether the container should be auto-started.Valid values are 0 (off) and 1 (on).
lxc.start.delay: How long to wait (in seconds) after the container isstarted before starting the next one.
lxc.start.order: An integer used to sort the containers when auto-startinga series of containers at once. A lower value means anearlier start.
lxc.monitor.unshare: If not zero the mount namespace will be unshared from the hostbefore initializing the container (before running any pre-starthooks). This requires the CAP_SYS_ADMIN capability at startup.Default is 0.
lxc.monitor.signal.pdeath: Set the signal to be sent to the container's init when the lxcmonitor exits. By default it is set to SIGKILL which will causeall container processes to be killed when the lxc monitor processdies.To ensure that containers stay alive even if lxc monitor dies setthis to 0.
lxc.group: A multi-value key (can be used multiple times) to put thecontainer in a container group. Those groups can then beused (amongst other things) to start a series of relatedcontainers.

AUTOSTART AND SYSTEM BOOT

Each container can be part of any number of groups or no group at all.Two groups are special. One is the NULL group, i.e. the container doesnot belong to any group. The other group is the "onboot" group.

When the system boots with the LXC service enabled, it will firstattempt to boot any containers with lxc.start.auto == 1 that is a memberof the "onboot" group. The startup will be in order of lxc.start.order.If an lxc.start.delay has been specified, that delay will be honoredbefore attempting to start the next container to give the currentcontainer time to begin initialization and reduce overloading the hostsystem. After starting the members of the "onboot" group, the LXC systemwill proceed to boot containers with lxc.start.auto == 1 which are notmembers of any group (the NULL group) and proceed as with the onbootgroup.

CONTAINER ENVIRONMENT

If you want to pass environment variables into the container (thatis, environment variables which will be available to init and all ofits descendents), you can use lxc.environmentparameters to do so. Be careful that you do not pass in anythingsensitive; any process in the container which doesn't have itsenvironment scrubbed will have these variables available to it, andenvironment variables are always available via/proc/PID/environ.

This configuration parameter can be specified multiple times; oncefor each environment variable you wish to configure.

lxc.environment

Specify an environment variable to pass into the container.Example:

 lxc.environment = APP_ENV=production lxc.environment = SYSLOG_SERVER=192.0.2.42

It is possible to inherit host environment variables by setting thename of the variable without a "=" sign. For example:

 lxc.environment = PATH

EXAMPLES

In addition to the few examples given below, you will findsome other examples of configuration file in /usr/share/doc/lxc/examples

NETWORK

This configuration sets up a container to use a veth pairdevice with one side plugged to a bridge br0 (which has beenconfigured before on the system by the administrator). Thevirtual network device visible in the container is renamed toeth0.

 lxc.uts.name = myhostname lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.name = eth0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597

UID/GID MAPPING

This configuration will map both user and group ids in therange 0-9999 in the container to the ids 100000-109999 on the host.

 lxc.idmap = u 0 100000 10000 lxc.idmap = g 0 100000 10000

CONTROL GROUP

This configuration will setup several control groups forthe application, cpuset.cpus restricts usage of the defined cpu,cpus.share prioritize the control group, devices.allow makesusable the specified devices.

 lxc.cgroup.cpuset.cpus = 0,1 lxc.cgroup.cpu.shares = 1234 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rw lxc.cgroup.devices.allow = b 8:0 rw

COMPLEX CONFIGURATION

This example show a complex configuration making a complexnetwork stack, using the control groups, setting a new hostname,mounting some locations and a changing root file system.

 lxc.uts.name = complex lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.hwaddr = 4a:49:43:49:79:bf lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255 lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597 lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588 lxc.net.1.type = macvlan lxc.net.1.flags = up lxc.net.1.link = eth0 lxc.net.1.hwaddr = 4a:49:43:49:79:bd lxc.net.1.ipv4.address = 10.2.3.4/24 lxc.net.1.ipv4.address = 192.168.10.125/24 lxc.net.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596 lxc.net.2.type = phys lxc.net.2.flags = up lxc.net.2.link = dummy0 lxc.net.2.hwaddr = 4a:49:43:49:79:ff lxc.net.2.ipv4.address = 10.2.3.6/24 lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297 lxc.cgroup.cpuset.cpus = 0,1 lxc.cgroup.cpu.shares = 1234 lxc.cgroup.devices.deny = a lxc.cgroup.devices.allow = c 1:3 rw lxc.cgroup.devices.allow = b 8:0 rw lxc.mount.fstab = /etc/fstab.complex lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0 lxc.rootfs.path = dir:/mnt/rootfs.complex lxc.rootfs.options = idmap=container lxc.cap.drop = sys_module mknod setuid net_raw lxc.cap.drop = mac_override

AUTHOR

Daniel Lezcano <daniel.lezcano@free.fr>

Index

NAME

DESCRIPTION

CONFIGURATION
ARCHITECTURE
HOSTNAME
HALT SIGNAL
REBOOT SIGNAL
STOP SIGNAL
INIT COMMAND
INIT WORKING DIRECTORY
INIT ID
PROC
EPHEMERAL
NETWORK
NEW PSEUDO TTY INSTANCE (DEVPTS)
CONTAINER SYSTEM CONSOLE
CONSOLE THROUGH THE TTYS
CONSOLE DEVICES LOCATION
/DEV DIRECTORY
MOUNT POINTS
ROOT FILE SYSTEM
CONTROL GROUPS ("CGROUPS")
CAPABILITIES
NAMESPACES
RESOURCE LIMITS
SYSCTL
APPARMOR PROFILE
SELINUX CONTEXT
KERNEL KEYRING
SECCOMP CONFIGURATION
PR_SET_NO_NEW_PRIVS
UID MAPPINGS
CONTAINER HOOKS
CONTAINER HOOKS ENVIRONMENT VARIABLES
LOGGING
AUTOSTART
AUTOSTART AND SYSTEM BOOT
CONTAINER ENVIRONMENT

EXAMPLES

NETWORK
UID/GID MAPPING
CONTROL GROUP
COMPLEX CONFIGURATION

SEE ALSO

AUTHOR

This document was created byman2html,using the manual pages.
Time: 04:45:15 GMT, June 08, 2024