If liblxc is used multi-threaded do_lxcapi_save_config() could be called from
threads that fork() which to not risk ending up with invalid locking states we
should avoid using functions like fopen() that internally allocate memory and
use locking. Let's replace it with the async-signal safe combination of
open() + write().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Sigh, this is going to be fun. Essentially, dynamic memory allocation through
malloc() and friends is unsafe when fork()ing in threads. The locking state
that glibc maintains internally might get messed up when the process that
fork()ed calls malloc or calls functions that malloc() internally. Functions
that internally malloc() include fopen(). One solution here is to use open() +
mmap() instead of fopen() + getline().
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This reverts commit 7995662124.
Before we can merge something like this we need to have it be behind a
configure flag and quite probably be an opt-in feature (--enable-pam).
This should fix Jenkins, PPA builds and the current binary conflicts
between the lxcfs and lxc package builds (snap and archive).
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
The time has come to remove the cgfs cgroup driver as well. I'm doing this for
mainly two reasons:
- potential security issue:
The cgfs cgroup driver has been unmaintained for a long time now. It did not
receive new functionality apart from bugfixes. Now that cgroup2 is a thing
the internal logic how to deal with cgroups has been substantially reworked
for the cgfsng driver. Given that we won't do the same work for the cgfs
driver I smell bugs all over the place in the near future. I don't want to
wake up to a security issue where someone forces LXC to fallback to the cgfs
driver to exploit bugs when e.g. running in a pure unified cgroup layout.
- code complexity:
The cgfs cgroup driver is massively complex since it tried to figure out
where the mountpoint for each legacy cgroup hierarchy is, i.e. it didn't make
simplyfing assumptions like cgfsng does about where the cgroup hierarchies -
legacy or unified - would be mounted. This was appropriate before cgroup
mounting has been standardized. Nowadays, anyone who mounts cgroups not under
/sys/fs/cgroup is on their own. Furthermore, with unified hierarchy cgroup
layouts there will only be a single hierarchy mounted at /sys/fs/cgroup so
there's even less need to drag the complex parsing in cgfs into the future.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This enables cgroup-full:{mixed,ro,rw}:force and reworks the mount logic.
When cgroup-full was specified we used to bind-mount the cgroups from the host.
That is pretty weird thing to do given that you can simply mount them directly
without going through bind-mounts.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
