overlay: support "userxattr" option (kernel 5.11)#5076
overlay: support "userxattr" option (kernel 5.11)#5076dmcgowan merged 1 commit intocontainerd:masterfrom
Conversation
5b6c094 to
492f06f
Compare
|
Build succeeded.
|
There was a problem hiding this comment.
Why make this public and not put it in the checks.go file
There was a problem hiding this comment.
Expected to be imported by stargz-snapshotter.
Also perhaps by Moby: moby/moby#42068
492f06f to
28ace94
Compare
|
Build succeeded.
|
There was a problem hiding this comment.
Could we just ignore the error here to ensure that this is very safe?
There was a problem hiding this comment.
There is already quite a few errors ignored in the function and should only trigger errors if already in the user namespace.
@AkihiroSuda if we were to always ignore errors here, will it always error out on running containers in 5.11 and later? Plugin load errors are rare, but would that be less confusing than just having the mount errors later on.
There was a problem hiding this comment.
if we were to always ignore errors here, will it always error out on running containers in 5.11 and later?
- rootful is unaffected
- Yes for most rootless containers, but not "always"
There was a problem hiding this comment.
I think the cleanest solution here is to just have the NeedsUserXattr return errors if it wasn't able to make that determination then just warn about that error here. Considering it is just a flag which gets put on the mount, there shouldn't be a need to fail loading the whole overlay plugin. It is reasonable to log that at warn or error level though, since it shouldn't occur under normal circumstances.
There was a problem hiding this comment.
changed return err to logrus.Warn
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 5060 Signed-off-by: Akihiro Suda <[email protected]>
Required for rootless overlayfs on kernel 5.11 containerd/containerd#5076 Signed-off-by: Akihiro Suda <[email protected]>
Required for rootless overlayfs on kernel 5.11 containerd/containerd#5076 Signed-off-by: Akihiro Suda <[email protected]>
Vendor https://github.com/AkihiroSuda/containerd/commits/buildkit/v0.8/20210311 . This revision is forked from containerd/containerd@0edc412 (20201117) with `overlay: support "userxattr" option (kernel 5.11)` (containerd/containerd#5076) Relates to moby#2013 Signed-off-by: Akihiro Suda <[email protected]>
ref: containerd/containerd#5076 Signed-off-by: Akihiro Suda <[email protected]>
ref: containerd/containerd#5076 Signed-off-by: Akihiro Suda <[email protected]>
ref: containerd/containerd#5076 Signed-off-by: Akihiro Suda <[email protected]>
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
Fix issue #5060