-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Replace Cgroup Parent and Name fields by CgroupsPath #497
Conversation
// path resulting from prepending another path will always resolve to lexically | ||
// be a subdirectory of the prefixed path. This is all done lexically, so paths | ||
// that include symlinks won't be safe as a result of using pathClean. | ||
func pathClean(path string) string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NACK on removing this. It fixes a security vulnerability. Please use this function to clean paths that need to be scoped to a mountpoint, not filepath.Clean
.
EDIT: Ah, you've just moved it. Still NACK, moving it means that Docker will have a security regression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have noted that, yes.
What about making it a public method within the libcontainer/utils package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM. There are probably some other places where we aren't cleaning paths properly.
bb9396d
to
b4e1930
Compare
I think we are waiting for opencontainers/runtime-spec#270 |
Ah, I missed opencontainers/runtime-spec#270 somehow, sorry. For systemd, I tried to get the same result as before. I'll double check on a vm tomorrow in case I missed something (I basically runc a busybox with Do we have a systemd expert in the contributors? |
config: c, | ||
pid: pid, | ||
root: root, | ||
cgroupspath: libcontainerUtils.CleanPath(c.CgroupsPath), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, why isn't this just called path
? After all, the struct is called cgroupData
.
@mlaventure I'm not a systemd expert (@LK4D4 is the closest we have AFAIK), but I've dealt with my fair share of systemd bugs recently. TransientUnits require a slice and a unit name. They are then concatenated. AFAICS |
It's more like a strategy problem, something like, if we demand cgroupsPath to be absolute (as specs required), if user use |
@hqhq Well, the slice names you've given aren't valid. It would be more like We'd need to do some parsing on our side... Unless I'm mistaken and systemd understands paths as slice names. |
On docker side, we can just concatenate For systemd, I just realize that runc always uses fs regardless of whether systemd is installed on the localhost or not. We only do the detection when doing the test. I'll have to redo my testing. |
So, even master does not currently play nice with systemd (at least in my ubuntu 15.10 vm). It fails with the following
Since this is 100% systemd specific, |
For systemd, we create the scope using the dbus APIs and then manipulation is done by fs. Creating the scope using dbus is important because systemd does more than just create the paths. |
@mrunalp , yes we do. But by default we use the path as retrieved from The issue is that this path is in an invalid format. It would need to either be converted to an appropriate format or we should instead use |
@mlaventure venture Can you please share the command you used on
Which all work (although the last one causes warnings about missing kernel features because we aren't expanding paths the way that systemd does with Really, we should rethink how we're dealing with systemd's transient units IMHO. I can take a look at this later. |
Actually, the output of |
@cyphar |
#511 actually solves the above issue I describe about incorrect cgroup paths. @mlaventure Can you share the code you used to add the systemd check? |
@cyphar I've used this: diff --git a/libcontainer/factory_linux.go b/libcontainer/factory_linux.go
index ae5db9c..0700355 100644
--- a/libcontainer/factory_linux.go
+++ b/libcontainer/factory_linux.go
@@ -114,7 +114,9 @@ func New(root string, options ...func(*LinuxFactory) error) (Factory, error) {
CriuPath: "criu",
}
InitArgs(os.Args[0], "init")(l)
- Cgroupfs(l)
+ if l.NewCgroupsManager != nil {
+ Cgroupfs(l)
+ }
for _, opt := range options {
if err := opt(l); err != nil {
return nil, err
diff --git a/utils.go b/utils.go
index baffef1..8015d39 100644
--- a/utils.go
+++ b/utils.go
@@ -9,6 +9,7 @@ import (
"github.com/codegangsta/cli"
"github.com/opencontainers/runc/libcontainer"
+ "github.com/opencontainers/runc/libcontainer/cgroups/systemd"
"github.com/opencontainers/runc/libcontainer/configs"
"github.com/opencontainers/specs"
)
@@ -104,7 +105,14 @@ func loadFactory(context *cli.Context) (libcontainer.Factory, error) {
if err != nil {
return nil, err
}
- return libcontainer.New(abs, libcontainer.Cgroupfs, func(l *libcontainer.LinuxFactory) error {
+ var newCgroupFunc func(l *libcontainer.LinuxFactory) error
+ if systemd.UseSystemd() {
+ newCgroupFunc = libcontainer.SystemdCgroups
+ } else {
+ newCgroupFunc = libcontainer.Cgroupfs
+ }
+
+ return libcontainer.New(abs, newCgroupFunc, func(l *libcontainer.LinuxFactory) error {
l.CriuPath = context.GlobalString("criu")
return nil
}) |
@mlaventure Yeah I've done this before #325 |
b4e1930
to
b90f4ef
Compare
Parent string `json:"parent"` | ||
// CgroupsPath specifies the path to cgroups that are created and/or joined by the container. | ||
// The path is assumed to be relative to the host system cgroup mountpoint. | ||
CgroupsPath string `json:"cgroupsPath"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would just call this Path
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
b90f4ef
to
74b857a
Compare
|
c := &configs.Cgroup{ | ||
Name: name, | ||
Parent: myCgroupPath, | ||
Path: filepath.Join(myCgroupPath, name), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you need to do a join here with name right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it depends, if I have a bundle named busybox
and set my cgroup path to be foo/bar
Do we want to use <cgroup-mount-point>/foo/bar/busybox
or <cgroup-mount-point>/foo/bar
when setting the rules?
Atm the code produce the former; if we want the later, I'm not sure what is the use for name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
Fixes opencontainers#396 Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
74b857a
to
256f3a8
Compare
|
LGTM |
1 similar comment
LGTM |
Replace Cgroup Parent and Name fields by CgroupsPath
It turns out that EDIT: It also makes cgroup paths unsafe (even though I'm sure the earlier version of this patch didn't cause this issue). Thank god I added a regression test for invalid cgroup paths in Docker, this could've ended badly. o.O I'm not sure this should've been merged. #552 fixes the issues I could find. |
When CgroupsPath code was introduced with opencontainers#497 it was mistakenly made to act as the equivalent of docker CgroupsParent. This ensure that it is taken as the final cgroup path. A couple of unit tests have been added to prevent future regression. Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Fixes #396
Closes #397
Closes #399
Signed-off-by: Kenfe-Mickael Laventure mickael.laventure@gmail.com
Since #397 and #399 haven't been touched in a month, I've made this PR.
This hopefully includes all decisions following the discussions in the aforementioned PRs.
However, since #466 was merged, we may need a better name than CgroupsPath now that we have a "Paths" member, but I couldn't come up with a better name. Open to suggestions.