Skip to content

overlay2: support "userxattr" option (kernel 5.11)#42068

Merged
cpuguy83 merged 2 commits intomoby:masterfrom
AkihiroSuda:ovl-k511
Mar 18, 2021
Merged

overlay2: support "userxattr" option (kernel 5.11)#42068
cpuguy83 merged 2 commits intomoby:masterfrom
AkihiroSuda:ovl-k511

Conversation

@AkihiroSuda
Copy link
Copy Markdown
Member

@AkihiroSuda AkihiroSuda commented Feb 24, 2021

- What I did

Fix #42055 "[kernel 5.11 + overlay2 + rootless] : apt-get fails with Invalid cross-device link"

- How I did it

Support "userxattr" option (kernel 5.11).

The "userxattr" option is needed for mounting overlayfs inside a user namespace with kernel >= 5.11.

The "userxattr" option is NOT needed for the initial user namespace (aka "the host").

Also, Ubuntu (since circa 2015) and Debian (since 10) with kernel < 5.11 can mount the overlayfs in a user namespace without the "userxattr" option.

The corresponding kernel commit: torvalds/linux@2d2f2d7

ovl: user xattr

Optionally allow using "user.overlay." namespace instead of "trusted.overlay."
...
Disable redirect_dir and metacopy options, because these would allow privilege escalation through direct manipulation of the
"user.overlay.redirect" or "user.overlay.metacopy" xattrs.

Related to containerd/containerd#5076

- How to verify it

- Description for the changelog

overlay2: support "userxattr" option (kernel 5.11)

- A picture of a cute animal (not mandatory but encouraged)
🐧

Comment thread daemon/graphdriver/overlay2/overlay.go Outdated
@AkihiroSuda
Copy link
Copy Markdown
Member Author

Moving out of draft.

@thaJeztah @tiborvass @StefanScherer Can we have a new release with this ASAP, before people begin using kernel 5.11 next month (Ubuntu 21.04 & Fedora 34)?

Comment thread daemon/graphdriver/overlay2/overlay.go Outdated
Comment thread daemon/graphdriver/overlay2/overlay.go Outdated
The "userxattr" option is needed for mounting overlayfs inside a user namespace with kernel >= 5.11.

The "userxattr" option is NOT needed for the initial user namespace (aka "the host").

Also, Ubuntu (since circa 2015) and Debian (since 10) with kernel < 5.11 can mount the overlayfs in a user namespace without the "userxattr" option.

The corresponding kernel commit: 2d2f2d7322ff43e0fe92bf8cccdc0b09449bf2e1
> **ovl: user xattr**
>
> Optionally allow using "user.overlay." namespace instead of "trusted.overlay."
> ...
> Disable redirect_dir and metacopy options, because these would allow privilege escalation through direct manipulation of the
> "user.overlay.redirect" or "user.overlay.metacopy" xattrs.

Fix issue 42055

Related to containerd/containerd PR 5076

Signed-off-by: Akihiro Suda <[email protected]>
Comment on lines +69 to +71
if err := os.RemoveAll(tdRoot); err != nil {
logrus.WithError(err).Warnf("Failed to remove check directory %v", tdRoot)
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we're removing here, but also in the defer? Is this to cleanup the test-dir from a previous daemon start?

(if so; would it be better to create a tempdir, so that we don't reuse the same directory?)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intentionally reusing the same directory to avoid filling up the root directory with unmountable dirs. Discussed in containerd/containerd#5076 (comment)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thanks for explaining, yes, that makes sense.

I think a comment explaining would be useful (perhaps an inline cleanup() function that's called both here, and in the defer, but ok to leave for a follow-up)

userxattr = "userxattr,"
}

logger.Debugf("backingFs=%s, projectQuotaSupported=%v, indexOff=%q, userxattr=%q",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove this from the init?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This Debugf is not new in this PR.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm personally ok with keeping this (for now) as it's not new indeed.

Looking at the code, I also want to do some refactoring after this is merged; the string-concatting code is becoming a bit messy and, assuming that won't affect performance, I'd like to use a []string for these options, and strings.Join() them at the end (I think that will make the code more readable).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this was a github UI issue, its not in the init like I thought.

Copy link
Copy Markdown
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


opts := []string{
fmt.Sprintf("lowerdir=%s:%s,upperdir=%s,workdir=%s", filepath.Join(td, "lower2"), filepath.Join(td, "lower1"), filepath.Join(td, "upper"), filepath.Join(td, "work")),
"userxattr",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can probably combine this check with SupportsOverlay() (adding a parameter to check with userxattr set); I'll look at that in a follow-up

@AkihiroSuda
Copy link
Copy Markdown
Member Author

@thaJeztah @tonistiigi

Can we merge this PR as-is without revendoring containerd, or do we need to revendor containerd/containerd#5204 ?

This needs to be cherry-picked into v20.10 (ASAP), so I'm not sure we want to revendor containerd.

@thaJeztah
Copy link
Copy Markdown
Member

Can we merge this PR as-is without revendoring containerd, or do we need to revendor containerd/containerd#5204 ?
This needs to be cherry-picked into v20.10 (ASAP), so I'm not sure we want to revendor containerd.

yes; we should merge this with the current (copied) code, especially for that reason (we don't want to be updating containerd vendor code in the 20.10 branch, unless there's a really important reason).

After this is merged, we can look at re-vendoring containerd (I'll be opening a PR today probably, to test) for 21.xx

@thaJeztah
Copy link
Copy Markdown
Member

@cpuguy83 PTAL

Copy link
Copy Markdown
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[kernel 5.11 + overlay2 + rootless] : apt-get fails with Invalid cross-device link

4 participants