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 <peb@debian.org> 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_<syscall-name> being defined. But
__NR_<syscall-name> 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_<syscall-name> 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 <peb@debian.org> 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 <peb@debian.org> 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 <evgeni@debian.org> Sun, 31 Jan 2016 18:22:40 -0200