thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
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>

thread_safety: s/exit()/_exit()/g
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>

thread-safety: s/exit()/_exit()/g
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>

doc: Add cgroup-full:*:force to Japanese lxc.container.conf(5)

Update for commit e7806b2eSigned-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

cgfsng: fix off-by-one error

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

This reverts commit 79956621.

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>

pam: create writable cgroups for unpriv users

doc: document cgroup-full:{mixed,ro,rw}:force

Update Japanese lxc.container.conf(5)

Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

Update for commit 3f69fb12, and and reduce commentnized English line.
Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

Update for commit d840039eSigned-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

Update for commit 46186acdSigned-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

change from lxc.namespace.* to lxc.namespace.share.*.
Update for commit b074bbf1Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

Update for commit 54860ed0Signed-off-by: KATOH Yasufumi <karma@jazz.email.ne.jp>

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

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

tree-wide: coding style + fixes

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

Signed-off-by: Christian Brauner <christian.brauner@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>

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>

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