- 21 Feb, 2018 20 commits
-
-
Christian Brauner authored
Signed-off-by:Christian Brauner <christian.brauner@ubuntu.com>
-
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
s/must_prefix_named/cg_legacy_must_prefix_named/ Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
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:Shukui Yang <yangshukui@huawei.com> Signed-off-by:
-
- 17 Feb, 2018 11 commits
-
-
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
If the handler closes the file descriptor for the peer or master fd it is crucial that we mark it as -EBADF. This will prevent lxc_console_delete() from calling close() on an already closed file descriptor again. I've observed the double close in the attach code. Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
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: -
Christian Brauner authored
This is really taking a long time for not a lot of benefit. Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Christian Brauner authored
They shouldn't be needed anymore. Signed-off-by:
-
- 12 Feb, 2018 9 commits
-
-
Yifeng Tan authored
Closes #810. Signed-off-by:
Yifeng Tan <tanyifeng1@huawei.com> Signed-off-by:
-
LiFeng authored
The variable 'descr' is mistakenly covered with 'descr_console'. Signed-off-by:LiFeng <lifeng68@huawei.com>
-
LiFeng authored
add: src/lxc/cmd/lxc-checkconfig src/lxc/cmd/lxc-update-config Signed-off-by: -
Christian Brauner authored
Signed-off-by: -
Tycho Andersen authored
In both of these cases if there is actually an error, we won't close the pipe and the api call will hang. Instead, let's be sure to close the pipe before waiting, so that it doesn't hang. Signed-off-by:Tycho Andersen <tycho@tycho.ws>
-
Christian Brauner authored
Dereference after null check Signed-off-by: -
Christian Brauner authored
Argument cannot be negative Signed-off-by: -
Christian Brauner authored
Resource leak Signed-off-by: -
Serge Hallyn authored
The only cases where we really need to be privileged with respect to the host is when we are trying to mknod, and in some cases to do with a physical network device. This patch leaves the detection of the network device cases as a TODO. This should fix the currently broken case of starting a privileged container with at least one veth nic, nested inside an unprivileged container. Cc: Tycho Andersen <tycho@tycho.ws> Signed-off-by:Serge Hallyn <shallyn@cisco.com>
-
