d/g/overlayutils: improve SupportsOverlay checks#45890
d/g/overlayutils: improve SupportsOverlay checks#45890neersighted wants to merge 3 commits intomoby:masterfrom
Conversation
neersighted
added
area/storage/overlay
status/2-code-review
kind/bugfix
neersighted
force-pushed
the
better_supportsoverlay
branch
from
225ff4c to
952873e
Compare
We now do a function test for SELinux, in order to ensure that future improvements to the kernel/RootlessKit are detected instead of hardcoding assumptions. Likewise, we make sure to check `selinux.GetEnabled()` in case the RootlessKit workaround becomes unnecessary. Signed-off-by: Bjorn Neergaard <[email protected]>
No functional changes, simply restructure the existing implementation to be a bit easier to read. Signed-off-by: Bjorn Neergaard <[email protected]>
neersighted
force-pushed
the
better_supportsoverlay
branch
from
952873e to
8848b30
Compare
Signed-off-by: Bjorn Neergaard <[email protected]>
neersighted
force-pushed
the
better_supportsoverlay
branch
from
8848b30 to
111fe76
Compare
| if err := os.WriteFile(f3, []byte{}, 0o700); err != nil { | ||
| return err | ||
| } | ||
| err = unix.Renameat2(0, f3, 0, f4, unix.RENAME_WHITEOUT) |
There was a problem hiding this comment.
The manpage says that renameat2(RENAME_WHITEOUT) will fail with EPERM if the caller does not have the CAP_MKNOD capability. Could this result in false negatives (i.e. detect it is unsupported when the kernel and backing fs actually do support it) in Rootless Docker? Perhaps this check should be more limited, considering it a failure iff the error is EINVAL, or considering EPERM to be "inconclusive?" Or is there some sequence of operations we could perform on the overlayfs to indirectly test the filesystem support for RENAME_WHITEOUT without needing the process to have that capability?
|
Based on discussion in openzfs/zfs#8648 , would it be correct to assume that issues such as #46337 will be solved if one is running on OpenZFS 2.2+ (once it's released) without these improved OverlayFS checks? |
Yes. See my comment on 46337, with experiments. |
5 participants
docker pullinside rootless LXC: failed to register layer: ApplyLayer exit status 1 stdout: stderr: unlinkat #45884- What I did
Adjust the logic in
SupportsOverlay, to both check for SELinux support more holistically, and to check the underlying filesystem for support for vfs operations required by overlayfs in some cases, but that don't prevent a mount.This prevents recent versions of OpenZFS that don't truly support overlayfs from being selected for use.
- How I did it
Reading the kernel source/experimentally.
- How to verify it
TODO
- Description for the changelog
TODO
- A picture of a cute animal (not mandatory but encouraged)