oci: layer: add support for userxattr in OverlayfsRootfs #587
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Our xattr tests in particular incorrectly re-used the same rootfs for both on-disk formats, which happened to work because the subtest ordering resulted in correct behaviour, but changing the test names caused those tests to fail. Fixes: 9a1cefa ("oci: layer: correctly handle trusted.overlay xattr namespace escaping") Signed-off-by: Aleksa Sarai <[email protected]>
|
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #587 +/- ##
==========================================
+ Coverage 72.58% 73.74% +1.16%
==========================================
Files 68 69 +1
Lines 5424 5493 +69
==========================================
+ Hits 3937 4051 +114
+ Misses 1104 1060 -44
+ Partials 383 382 -1
🚀 New features to boost your workflow:
|
Member
Author
cyphar
force-pushed
the
overlayfs-userxattr
branch
from
c58a418 to
6bd7436
Compare
This was
linked to
issues
May 20, 2025
…onfig Previously we had separate ways of specifying the on-disk format with UnpackOptions and RepackOptions (UnpackOptions had an enum for the on-disk format while RepackOptions just had a boolean specifying whether overlayfs-style whiteouts should be translated). Conceptually it makes far more sense to think of the configuration as being an "on-disk format", so we should represent it that way in the configuration. In addition to the on-disk format type, the userns mapping applied to the rootfs is more a property of the on-disk format than being a standalone option. By creating an OnDiskFormat interface that has multiple implementations we can also add per-on-disk-format configuration options (such as userxattr for the overlayfs on-disk-format, which will be added later in this series). Signed-off-by: Aleksa Sarai <[email protected]>
…lter This doesn't happen in practice (because filters are retrieved based on their xattr prefix), but it's useful when writing unit tests of our behaviour. Signed-off-by: Aleksa Sarai <[email protected]>
Since "" is an invalid xattr, we don't need to mess around with *string to indicate that an xattr should be removed. Signed-off-by: Aleksa Sarai <[email protected]>
Since Linux 5.11, overlayfs supports using "user.overlay." as the xattr namespace for special overlayfs xattrs (rather than the default "trusted.overlay.") when mounted using the "userxattr" mount option. This is a key part of unprivileged overlayfs mounting. For the most part, supporting this is fairly straightforward now that the on-disk format is represented with OverlayfsRootfs -- all hardcoded references to "trusted.overlay." just need to take into account the value of OverlayfsRootfs.UserXattr. Downstreams like stacker have had out-of-tree patches to support operating on these xattrs for a long time (since they use unprivileged overlayfs mounts whenever possible), so supporting it in a more structured way should be very welcome. One key thing to note is that (just like overlayfs) we only ever treat one of "trusted.overlay." or "user.overlay." as special. The existing tests also only needed miminal adjustments, and include tests to make sure that we only ever touch the appropriate namespace. This also finally allows us to run the overlayfs tests as an unprivileged user. Signed-off-by: Aleksa Sarai <[email protected]>
cyphar
force-pushed
the
overlayfs-userxattr
branch
from
6bd7436 to
7d2d5e5
Compare
cyphar
added a commit
to cyphar/stacker
that referenced
this pull request
May 31, 2025
This allows us to switch away from our umoci fork now that upstream supports OverlayfsRootfs and the various features we need. The key changes that allow us to switch away from our fork are: * opencontainers/umoci#572 which implemented a large number of fixes to overlayfs handling, such as opaque whiteouts and several features not implemented in our fork (xattr escaping, handling of missing parent directories, improved rootless support, handling of nested whiteouts inside an opaque whiteout). * opencontainers/umoci#581 which switched to a Docker-friendly gzip block size by default, removing the need to configure it (as suggested in opencontainers/umoci#509). * opencontainers/umoci#587 which implemented full configurable userxattr (user.overlay.*) support. Signed-off-by: Aleksa Sarai <[email protected]>
rchincha
pushed a commit
to project-stacker/stacker
that referenced
this pull request
May 31, 2025
* feat: update to skopeo v1.13.0 We need to update skopeo to match the pgzip version between skopeo and umoci. Signed-off-by: Aleksa Sarai <[email protected]> * feat: update to github.com/opencontainers/[email protected] This allows us to switch away from our umoci fork now that upstream supports OverlayfsRootfs and the various features we need. The key changes that allow us to switch away from our fork are: * opencontainers/umoci#572 which implemented a large number of fixes to overlayfs handling, such as opaque whiteouts and several features not implemented in our fork (xattr escaping, handling of missing parent directories, improved rootless support, handling of nested whiteouts inside an opaque whiteout). * opencontainers/umoci#581 which switched to a Docker-friendly gzip block size by default, removing the need to configure it (as suggested in opencontainers/umoci#509). * opencontainers/umoci#587 which implemented full configurable userxattr (user.overlay.*) support. Signed-off-by: Aleksa Sarai <[email protected]> --------- Signed-off-by: Aleksa Sarai <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since Linux 5.11, overlayfs supports using "user.overlay." as the xattr
namespace for special overlayfs xattrs (rather than the default
"trusted.overlay.") when mounted using the "userxattr" mount option.
This is a key part of unprivileged overlayfs mounting.
For the most part, supporting this is fairly straightforward now that
the on-disk format is represented with OverlayfsRootfs -- all hardcoded
references to "trusted.overlay." just need to take into account the
value of OverlayfsRootfs.UserXattr. Downstreams like stacker have had
out-of-tree patches to support operating on these xattrs for a long time
(since they use unprivileged overlayfs mounts whenever possible), so
supporting it in a more structured way should be very welcome.
One key thing to note is that (just like overlayfs) we only ever treat
one of "trusted.overlay." or "user.overlay." as special. The existing
tests also only needed miminal adjustments, and include tests to make
sure that we only ever touch the appropriate namespace.
This also finally allows us to run the overlayfs tests as an
unprivileged user.
Implements #576
Implements #584
Signed-off-by: Aleksa Sarai [email protected]