Skip to content

L
lxc
Switch branch/tag
  1. 16 Feb, 2018 6 commits
    • Merge pull request #2170 from brauner/2018-02-16/cgfsng_force_cgroup_mount · 47d4e397
      Stéphane Graber authored 
      confile: add "force" to cgroup:{mixed,ro,rw}
    • utils: fix lxc_p{close,open}() · 7e50ec0b
      Christian Brauner authored 
      If a file descriptor fd is opened by fdopen() and associated with a stream f
will **not** have been dup()ed. This means that fclose(f) will also close the
fd. So never call close(fd) after fdopen(fd) succeeded.
This fixes a double close() Stéphane and I observed when debugging on aarch64
and armf.
Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • tests: remove lxc-test-ubuntu · e99cf4ac
      Christian Brauner authored 
      This is really taking a long time for not a lot of benefit.
Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • CODING_STYLE: add section for str{n}cmp() · ed06b69c
      Christian Brauner authored 
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • conf: non-functional changes · 8353b4c9
      Christian Brauner authored 
      Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
    • confile: add "force" to cgroup:{mixed,ro,rw} · 3f69fb12
      Shukui Yang authored 
      This lets users specify

        lxc.mount.auto = cgroup:mixed:force
or
        lxc.mount.auto = cgroup:ro:force
or
        lxc.mount.auto = cgroup:rw:force

When cgroup namespaces are supported LXC will not mount cgroups for the
container since it assumes that the init system will mount cgroups itself if it
wants to. This assumption already broke when users wanted to run containers
without CAP_SYS_ADMIN. For example, systemd based containers wouldn't start
since systemd needs to mount cgroups (named systemd hierarchy for legacy
cgroups and the unified hierarchy for unified cgroups) to track processes. This
problem was solved by detecting whether the container had CAP_SYS_ADMIN. If it
didn't we performed the cgroup mounts for it.
However, there are more cases when we should be able to mount cgroups for the
container when cgroup namespaces are supported:
- init systems not mounting cgroups themselves:
  A init system that doesn't mount cgroups would not have cgroups available
  especially when combined with custom LSM profiles to prevent cgroup
  {u}mount()ing inside containers.
- application containers:
  Application containers will usually not mount by cgroups themselves.
- read-only cgroups:
  It is useful to be able to mount cgroups read-only to e.g. prevent
  changing cgroup limits from inside the container while at the same time
  allowing the applications to perform introspection on their own cgroups. This
  again is mostly useful for application containers. System containers running
  systemd will usually not work correctly when cgroups are mounted read-only.
To be fair, all of those use-cases could be covered by custom hooks or
lxc.mount.entry entries but exposing it through lxc.mount.auto takes care of
setting correct mount options and adding the necessary logic to e.g. mount
filesystem read-only correctly.

Currently we only extend this to cgroup:{mixed,ro,rw} but technically there's
no reason not to enable the same behavior for cgroup-full:{mixed,ro,rw} as
well. If someone requests this we can simply treat it as a bug and add "force"
for cgroup-full.

Replaces #2136.
Signed-off-by: 's avatarShukui Yang <yangshukui@huawei.com>
Signed-off-by: 's avatarChristian Brauner <christian.brauner@ubuntu.com>
  3. 14 Feb, 2018 6 commits
  5. 13 Feb, 2018 5 commits
  7. 12 Feb, 2018 7 commits
  9. 11 Feb, 2018 2 commits
  11. 10 Feb, 2018 4 commits
  13. 09 Feb, 2018 10 commits