Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support --privileged --cgroupns=private on cgroup v1 #40788

Closed
AkihiroSuda opened this issue Apr 7, 2020 · 6 comments · Fixed by #40845
Closed

support --privileged --cgroupns=private on cgroup v1 #40788

AkihiroSuda opened this issue Apr 7, 2020 · 6 comments · Fixed by #40845
Labels
kind/enhancement Enhancements are not bugs or new features but can improve usability or performance.
Milestone

Comments

@AkihiroSuda
Copy link
Member

Description
--privileged --cgroupns=private on cgroup v1 should be supported.

Steps to reproduce the issue:

$ docker run --rm --privileged --cgroupns=private hello-world

Describe the results you received:

docker: Error response from daemon: privileged mode is incompatible with private cgroup namespaces on cgroup v1 host.  You must run the container in the host cgroup namespace when running privileged mode.
See 'docker run --help'.

Describe the results you expected:
It should work

Additional information you deem important (e.g. issue happens only occasionally):

Not sure why we didn't support --privileged --cgroupns=private on cgroup v1.
Couldn't figure out in #38377

Output of docker version:

Client:
 Version:           20.03.0-dev
 API version:       1.41
 Go version:        go1.13.9
 Git commit:        2f494e118
 Built:             Tue Apr  7 14:28:04 2020
 OS/Arch:           linux/amd64
 Experimental:      true

Server:
 Engine:
  Version:          dev
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.9
  Git commit:       a6a47d1a49
  Built:            Tue Apr  7 14:26:17 2020
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.3.0-468-g4660e4db
  GitCommit:        4660e4dbb653b4d83ffbc7b0dd21c9c2d2f10ea3
 runc:
  Version:          1.0.0-rc10+dev
  GitCommit:        d3fdacb92f4e82b4916900483d6a94caa3869041
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683
@AkihiroSuda AkihiroSuda added the kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. label Apr 7, 2020
@AkihiroSuda
Copy link
Member Author

cc @rgulewich @giuseppe

@thaJeztah
Copy link
Member

/cc @kolyshkin

@AkihiroSuda
Copy link
Member Author

@rgulewich WDYT?

@AkihiroSuda
Copy link
Member Author

PR: #40845

@rgulewich
Copy link
Contributor

@AkihiroSuda - When I originally implemented this, I had thought that a privileged container also meant having access to the host namespaces. If I'm understanding your comment here, the "correct" behaviour is for privileged containers to still get their own private namespaces, unless they explicitly request host namespaces? If that's the case, then this makes sense to me (and your PR seems reasonable).

@AkihiroSuda
Copy link
Member Author

The default behavior is unchanged

20.10 planning automation moved this from To do to Done May 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Enhancements are not bugs or new features but can improve usability or performance.
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

3 participants