Currently lxc.selinux.context.keyring is placed after
lxc.selinux.context in config_jump_table. This entails that if
lxc.selinux.context.keyring is specified, lxc.selinux.context will be
matched to that option. This commit places the
lxc.selinux.context.keyring before lxc.selinux.context
Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>

This commit fixes a off by 2 in config option parsing
(due to missing parenthesis). The error occurs if for instance
lxc.net.0.type is parsed. In that case, the .0 is removed from the
string. However, due to the missing parenthesis, the null terminating
character is off by two which means the modified config option would
be lxc.net.typepe instead of lxc.net.type.
Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>

Add keyring option

Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>

lxc set's up a new session keyring for every container by default.
There might be valid use-cases where this is not wanted / needed
(e.g. systemd by default creates a new session keyring anyway).
Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>

lxc set's up a new session keyring for every container by default.
If executed on an SELinux enabled system, by default, the keyring
inherits the label of the creating process. If executed with the
currently available SELinux policy, this means that the keyring
is labeled with the lxc_t type. Applications inside the container,
however, might expect that the keyring is labeled with a certain
context (and will fail to access the keyring if it's not explicitly
allowed in the global policy). This patch introduces the config
option lxc.selinux.context.keyring which enables to specify the
label of the newly created keyring. That is, the keyring can be
labeled with the label expected by the started application.
Signed-off-by: Maximilian Blenk <Maximilian.Blenk@bmw.de>

cgroups: fix default cgroup pattern

Signed-off-by: Kirill Petrov <yakutskkirill@mail.ru>

start: fix container killing logic

We need to account for the case where pidfd's are not supported by the kernel
in question.

Closes: #3254
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

network: Restore fixed MTU functionality

If MTU setting is provided in network device config then always use it rather than inheriting from the link device.

Affected both bridge and router veth modes.
Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>

test: increase timeout for api reboot tests

cgroup.c: fix memory leak at cgroup init failed

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: LiFeng <lifeng68@huawei.com>

network: improve veth device creation

This makes all the codepaths easier to follow and also moves and renames
devices in one single step.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

We can't delete by netdev->ifindex since that's the ifindex of the device in
the container, not on the host. The correct thing is done below.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

This allows us to avoid having to move the network device. It also allows us to
work around a kernel bug that in combination with a recent change in systemd
244 causes uses of systemd-networkd to not get an ip address.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

handle kernel version <--> header incompatibility

We might e.g. be compiled in a container with old kernel headers. In this
scenario CLONE_PIDFD will work but pidfd_send_signal() might not be detected
because __NR_pidfd_send_signal is not defined because the kernel headers don't
match the kernel version.

This explains and fixes test-suite hangs on Jenkins I've recently debugged.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

That should be more than enough to reboot.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

start: remove procfs pidfd support

Suppress useless udhcpc directory

The udhcpc directory is created with "mkdir -p" at the place dynamically specified by "busybox udhcpc --help".
Signed-off-by: Rachid Koucha <rachid.koucha@gmail.com>

Adaptation to latest busybox

Word repetition in comment

In busybox 1.30, the help of udhcpc for "-s" option changed:
--> busybox v1.27.2: -s,--script PROG	Run PROG at DHCP events (default /usr/share/udhcpc/default.script)
--> busybox v1.30.1: -s PROG		Run PROG at DHCP events (default /etc/udhcpc/default.script)
So, I changed the command line which extracts the script name to make it work for both versions
Signed-off-by: Rachid Koucha <rachid.koucha@gmail.com>

We'll only rely on proper anon-inode based pidfd support in the future.
There's no good reason to use the procfs fallback. All the fancy features we
might want to use are only available with anon-inode pidfds.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

create_run_template(): Double "will mount" in a comment
Signed-off-by: Rachid Koucha <rachid.koucha@gmail.com>

travis: enable -fsanitize=undefined

cmd: fix shebang

Signed-off-by: vikaig <vikaig99@gmail.com>

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

fd: only add valid fd to mainloop

Signed-off-by: dongxinhua <dongxinhua@huawei.com>