Matthias Hardt [Mon, 9 Mar 2020 18:58:22 +0000 (19:58 +0100)]
commands_utils: fix socket leak when adding state client
If lxc_add_state_client() is called with the container already being in the desired state the client fd will never be closed and is leaking. This is due to setting stay_connected in lxc_cmd for LXC_CMD_ADD_STATE_CLIENT. If the desired state isn't already achieved the client fd will later be closed by calling lxc_cmd_fd_cleanup() but in the other case the client configuration isn't added to the handlers
state clients. So the client fd has to be closed explicitely.
This is simply tested by starting container A and calling lxc-wait -n A -s RUNNING.
Matthias Hardt [Mon, 9 Mar 2020 14:53:11 +0000 (15:53 +0100)]
commands_utils: fix socket leak in when adding state client
If lxc_add_state_client() is called with the container already being in
the desired state the client fd will never be closed and is leaking.
This due to setting stay_connected in lxc_cmd for
LXC_CMD_ADD_STATE_CLIENT. If the desired state isn't already achieved
the client fd will later be closed by calling lxc_cmd_fd_cleanup() but
in the other case the client configuration isn't added to the handlers
state clients. So the client fd has to be closed explicitely.
This is simply tested by starting container A and calling lxc-wait -n A
-s RUNNING.
Thomas Parrott [Sun, 8 Mar 2020 18:28:44 +0000 (18:28 +0000)]
network: Adds short sleep between veth setup and neighbour proxy add
There is an intermittent issue, experienced on at least Ubuntu 18.04 (5.3.0-40-generic) and Alpine 3.11 (5.4.12-1-virt) when using the router network interface type that causes the IP proxy neighbour entries on the host side of the veth pair to not be created.
The `ip neigh add proxy` command returns without an error, however by the time the network up hook has started the IP neighbour proxy entries are no longer there (if they ever were).
I've also tested this using netlink rather than the ip command to add and both are equally affected.
Adding a short sleep between setting up the veth pair and adding the proxy entries appears to fix it.
Signed-off-by: Thomas Parrott <thomas.parrott@canonical.com>
container.conf: Fix option ordering in config_jump_table
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>
Maximilian Blenk [Thu, 30 Jan 2020 18:21:10 +0000 (19:21 +0100)]
container.conf: Add option to disable session keyring creation
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>
Maximilian Blenk [Wed, 29 Jan 2020 16:09:50 +0000 (17:09 +0100)]
container.conf: Add option to set keyring SELinux context
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>
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>
start: handle kernel header and kernel incompatability
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>
Rachid Koucha [Fri, 27 Dec 2019 07:49:00 +0000 (08:49 +0100)]
Adaptation to latest busybox
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
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>
projects / thirdparty / lxc.git / log
