cgroupns=private should be enabled by default for unified mode? #4363
Assignees
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
|
@AkihiroSuda: The label(s) In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci-robot
added
the
kind/feature
|
I'm generally in favor, though ideally I'd like a config option to allow it
to be switched to off by default by users and distros.
…On Tue, Oct 29, 2019, 07:09 OpenShift CI Robot ***@***.***> wrote:
@AkihiroSuda <https://github.com/AkihiroSuda>: The label(s) kind/(?)
cannot be applied. These labels are supported: platform/aws,
platform/azure, platform/baremetal, platform/google, platform/libvirt,
platform/openstack, ga
In response to this <#4363>:
*Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)*
/kind feature (?)
*Description*
In Moby (cgroup v1), cgroupns is not used by default because it was not
available in the kernel until kernel 4.6 (May 2016), and the default
behavior will not change on cgroup v1 environments, because changing the
default will break compatibility and surprise users.
Podman seems to have followed this behavior for both cgroup v1 mode and v2
mode.
But for cgroup v2, I'm wondering both Moby and Podman should switch to
enable cgroupns by default.
As the migration to cgroup v2 is already breaking compatibility, there is
no reason to hesitate enable cgroupns by default?
Instructions for interacting with me using PR comments are available here
<https://git.k8s.io/community/contributors/guide/pull-requests.md>. If
you have questions or suggestions related to my behavior, please file an
issue against the kubernetes/test-infra
<https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:>
repository.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4363>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3AOCGWEPXMPG4YDXJBMATQRAKVXANCNFSM4JGG5X6A>
.
|
|
I agree we need to add a flag to disable it. |
from the CLI, it can be disabled with Not sure that should be a blocker though. Changing the default should not matter for most users, I've already verified that containers with systemd as payload work fine. |
|
I'm fine with changing the default now as long as we add the config option
once we can
…On Tue, Oct 29, 2019, 13:39 Giuseppe Scrivano ***@***.***> wrote:
I agree we need to add a flag to disable it.
from the CLI, it can be disabled with --cgroupns=host, but we miss a way
to configure namespaces from the config file.
Not sure that should be a blocker though. Changing the default should not
matter for most users, I've already verified that containers with systemd
as payload work fine.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4363>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB3AOCGKF6FJSAG3S6PU6ADQRBYMFANCNFSM4JGG5X6A>
.
|
|
Yes lets add the option and I will have @QiWang19 Add the config to containers-conf PR, when we start doing Podman. |
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Oct 30, 2019
change the default on cgroups v2 and create a new cgroup namespace. When a cgroup namespace is used, processes inside the namespace are only able to see cgroup paths relative to the cgroup namespace root and not have full visibility on all the cgroups present on the system. The previous behaviour is maintained on a cgroups v1 host, where a cgroup namespace is not created by default. Closes: containers#4363 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
opened a PR here to change the default value: #4374 |
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Oct 30, 2019
change the default on cgroups v2 and create a new cgroup namespace. When a cgroup namespace is used, processes inside the namespace are only able to see cgroup paths relative to the cgroup namespace root and not have full visibility on all the cgroups present on the system. The previous behaviour is maintained on a cgroups v1 host, where a cgroup namespace is not created by default. Closes: containers#4363 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Oct 30, 2019
change the default on cgroups v2 and create a new cgroup namespace. When a cgroup namespace is used, processes inside the namespace are only able to see cgroup paths relative to the cgroup namespace root and not have full visibility on all the cgroups present on the system. The previous behaviour is maintained on a cgroups v1 host, where a cgroup namespace is not created by default. Closes: containers#4363 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Nov 5, 2019
change the default on cgroups v2 and create a new cgroup namespace. When a cgroup namespace is used, processes inside the namespace are only able to see cgroup paths relative to the cgroup namespace root and not have full visibility on all the cgroups present on the system. The previous behaviour is maintained on a cgroups v1 host, where a cgroup namespace is not created by default. Closes: containers#4363 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Nov 5, 2019
change the default on cgroups v2 and create a new cgroup namespace. When a cgroup namespace is used, processes inside the namespace are only able to see cgroup paths relative to the cgroup namespace root and not have full visibility on all the cgroups present on the system. The previous behaviour is maintained on a cgroups v1 host, where a cgroup namespace is not created by default. Closes: containers#4363 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe
added a commit
to giuseppe/libpod
that referenced
this issue
Nov 5, 2019
change the default on cgroups v2 and create a new cgroup namespace. When a cgroup namespace is used, processes inside the namespace are only able to see cgroup paths relative to the cgroup namespace root and not have full visibility on all the cgroups present on the system. The previous behaviour is maintained on a cgroups v1 host, where a cgroup namespace is not created by default. Closes: containers#4363 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
11 tasks
|
deploiement container avec linux ou ubuntu colonial |
AkihiroSuda
added a commit
to AkihiroSuda/docker
that referenced
this issue
Dec 31, 2019
For cgroup v1, we were unable to change the default because of compatibility issue. For cgroup v2, we should change the default right now because switching to cgroup v2 is already breaking change. See also containers/podman#4363 containers/podman#4374 Privileged containers also use cgroupns=private by default. containers/podman#4374 (comment) Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
AkihiroSuda
added a commit
to AkihiroSuda/cri-containerd
that referenced
this issue
Jan 9, 2020
In cgroup v1 container implementations, cgroupns is not used by default because it was not available in the kernel until kernel 4.6 (May 2016), and the default behavior will not change on cgroup v1 environments, because changing the default will break compatibility and surprise users. For cgroup v2, implementations are going to unshare cgroupns by default so as to hide /sys/fs/cgroup from containers. * Discussion: containers/podman#4363 * Podman PR (merged): containers/podman#4374 * Moby PR: moby/moby#40174 This PR enables cgroupns for containers, but pod sandboxes are untouched because probably there is no need to do. Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
docker-jenkins
pushed a commit
to docker/docker-ce
that referenced
this issue
Jan 9, 2020
For cgroup v1, we were unable to change the default because of compatibility issue. For cgroup v2, we should change the default right now because switching to cgroup v2 is already breaking change. See also containers/podman#4363 containers/podman#4374 Privileged containers also use cgroupns=private by default. containers/podman#4374 (comment) Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp> Upstream-commit: 19baeaca267d5710907ac1b3c3972d44725fe8ad Component: engine
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind feature (?)
Description
In Moby (cgroup v1), cgroupns is not used by default because it was not available in the kernel until kernel 4.6 (May 2016), and the default behavior will not change on cgroup v1 environments, because changing the default will break compatibility and surprise users.
Podman seems to have followed this behavior for both cgroup v1 mode and v2 mode.
But for cgroup v2, I'm wondering both Moby and Podman should switch to enable cgroupns by default.
As the migration to cgroup v2 is already breaking compatibility, there is no reason to hesitate enable cgroupns by default?
The text was updated successfully, but these errors were encountered: