lxc (1:4.0.6-2) unstable; urgency=medium A new way of handling unprivileged containers starting and attachment has been made available through the lxc-unpriv-start and lxc-unpriv-attach commands. See /usr/share/doc/lxc/README.Debian.gz for more details. -- Pierre-Elliott Bécue Fri, 11 Jun 2021 15:12:15 +0200 lxc (1:4.0.2-1~1) experimental; urgency=medium Major changes in the Debian packaging: 1. lxc-net is now enabled by default, and newly created containers will have networking by default. Major changes between LXC 3.0.x and LXC 4: 1. CGroupV2 support: LXC 4 supports the unified CGroup hierarchy, which means that the containers will now be able to handle a booted system with an init like systemd using the unified CGroup hierarchy. This has implications regarding the unprivileged containers, as a standard user can't get an empty CGroup by themselves. In that specific situation, libpam_cgfs is useless. A solution to run an unprivileged container as a standard non-root user is to use systemd-run: `systemd-run --user --scope -p "Delegate=yes" lxc-start container-name` The user instance of systemd will delegate an empty CGroup available and manipulable properly by the container. 2. The default AppArmor profile now denies access to /proc/acpi/. This was already the case in Debian but has been merged upstream. 3. config: Add lxc.autodev.tmpfs.size configuration key: LXC supports creating a useable minimal /dev directory for the container by setting lxc.autodev = 1 in the container’s config file. To do this LXC sets up a tmpfs mount on /dev. This tmpfs mount could not be restricted in prior releases. Now it is possible to set a limit on the size of the tmpfs mount by setting lxc.autodev.tmpfs.size to the number of bytes that the tmpfs should be restricted to use. 4. config: Add lxc.selinux.context.keyring key This allows one to specify the selinux context to be used for the keyring the container uses. 5. config: Add lxc.keyring.session Setting this to 1 (default) will cause LXC to create a new session keyring. Other changes: 1. Freezer support in CGroupV2: As part of the cgroup2 support work for LXC 4.0 support for cgroup2’s implementation of the freezer controller has been added. It allows one to poll until the cgroup is frozen or unfrozen making freezing and unfreezing container’s way more reliable than before. 2. file utils: Add fopen_cached() and fdopen_cached These helpers first read a whole file and then make it available as a stream to be read via regular file-based libc apis. This makes LXC’s handling of various files more robust where the underlying file can change while it is read. 3. PIDfd support LXC 4.0 fully supports the new pidfd kernel api the LXC team has merged in the upstream Linux kernel. The pidfd of the container’s init process can be requested via c->init_pidfd(c). 4. memory utils: Add new cleanup api LXC 4.0 expands the usage of the compiler’s cleanup attribute by introducing new internal apis to define and call cleanup macros for complex resource allocations. Significant results in decreasing bugs around file descriptor and memory leaks by switching to this new way of cleaning up resources have been observed. 5. lxc-usernsexec: Make it easy to map own uid The lxc-usernsexec binary now finds a default mapping as specified in /etc/subuid and /etc/subgid and writes it via newuidmap and newgidmap. 6. seccomp: Add s390 support LXC 4.0’s seccomp implementation now supports s390 as architecture. 7. syscalls: Improve manual syscall implementations Whenever a given syscall is not supported or exposed by the underlying C library of the system LXC will define syscall stubs for important syscalls or new features it deems extremely valuable. This used to be done by checking for __NR_ being defined. But __NR_ being defined depended on the correct headers for the currently running kernel LXC was compiled on being installed and would be problematic whenever LXC was compiled on a system running an older kernel but used or deployed on systems that use a new kernel. In such scenarios LXC could not make use of new kernel features even though it should. Definitions for __NR_ are introduced whenever the system does not define it already and it is a supported architecture (which is basically any architecture). This results in a better handling of kernel <-> header version mismatches and compilation <-> deployment kernel mismatches. 8. network: Improved network device creation and removal The way network devices are created, tracked, moved between network namespaces, and are removed has been reworked. This makes the low-level network management way more reliable. 9. network: Allow moving wireless devices LXC allowed to move wireless network devices (nl80211) into containers. This was broken for a while. With 4.0 the ability to move wireless network devices is restored and improved. -- Pierre-Elliott Bécue Thu, 15 Apr 2020 22:44:32 +0200 lxc (1:3.1.0+really3.0.3-6) unstable; urgency=medium LXC 3 got some significant changes from LXC 2. 1. The configuration files use different variables. A userland script lxc-update-config is available to update automatically your configuration files. An automatic update is possible and offered by debconf during the upgrade of lxc version < 3.0.2 to lxc version >= 3.0.2. Mind that this update will only work for privileged containers with configurations present in /var/lib/lxc/*/config and any other container will not be updated. 2. AppArmor support in Debian has increased, thus preventing some systemd isolation features to work in LXC 3.0.X. Debian has backported some patches from LXC 3.1 that, along with some configurations in a container, will allow systemd isolation features to work. The required configuration parameters are the ones which follow: lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 These parameters are provided in the `/etc/lxc/default.conf` file shipped with LXC 3. Hence, any newly created container will have these parameters set properly, except if you alter the aforementioned file. WARNING: Note that with these parameters, unprivileged containers won't be able to start. lxc.apparmor.profile must be set to either 'unconfined' or to 'lxc-container-default-cgns'. This can be done either in the unprivileged container configuration file or in the user's .config/lxc/default.conf file. 3. lxc-templates is deprecated by upstream. The new way of building containers is via their distrobuilder software. This software isn't in Debian Buster, and thus, we still provide lxc-templates. If you relied on it (eg, with lxc.include parameter in some configuration file), you should install lxc-templates in case it doesn't come by itself (via recommends). Otherwise you may experience issues after the upgrade. -- Pierre-Elliott Bécue Sat, 09 Mar 2019 13:09:05 +0100 lxc (1:1.1.5-1) unstable; urgency=medium LXC before 1.1 did silently ignore lxc.aa_profile if the kernel did not have the AppArmor mount feature (by checking for the existence of /sys/kernel/security/apparmor/features/mount/mask). As of LXC 1.1 it will error out with the following message in the log: Incomplete AppArmor support in your kernel If you really want to start this container, set lxc.aa_allow_incomplete = 1 in your container configuration file Debian does not ship with AppArmor enabled in the kernel by default, so this should not affect default installs. However if you have enabled AppArmor, your containers will fail to start after the upgrade. Please add "lxc.aa_allow_incomplete = 1" to your configuration to start AppArmor-secured containers until we have full support in the kernel. -- Evgeni Golov Sun, 31 Jan 2016 18:22:40 -0200