alexlarsson
commented
3 months ago I'm not sure we're actually wrong here. But these things are mind-bending, so maybe I'm mistaken.
Here is the situation this is targeting: We have an "image" that contains a traditional whiteout node. We want to create an erofs+overlayfs from this, such that when it is mounted (by root), the resulting file in the mount: a) Is not swallowed by the cfs overlayfs mount b) Is usable as a whiteout in a rootful overlayfs where the lowerdir is on the cfs mount c) Is usable as a whiteout in a userxattr overlayfs where the lowerdir is on the cfs mount
Now, lets focus on c. In the erofs image we create a regular file with the "user.overlay.whiteout" xattr set. Since the composefs overlayfs is rootful, this xattr is passed on as-is and works as a xwhiteout for a second userxattr mount. However, it needs the parent directory to be marked for overlayfs to handle it. So, we set "user.overlay.opaque" to "x" to mark this. This xattr also is not touched by the composefs overlay mount, so it is available as-is for the second level userxattr overlayfs mount.
I think maybe you misunderstood the reason for these xattrs. They are not because we want to mount the erofs image with userxattrs (that will not work for many reasons), but rather that the rootful overlayfs mount of the erofs image should produce a mount where the whiteout file is useful both for regular and userxattr mounts.
cgwalters
@alexlarsson I took a pass at https://github.com/containers/composefs/pull/282#discussion_r1615667462 (this is only 76.3% baked, I got a little lost a few times in the quoting/processing here) but I'm pretty sure now what we've been writing into the EROFS blob is wrong. If I'm right about that...I think there's two options:
user.namespace given that we can't mount an EROFS unprivileged anyways and that's super unlikely to change in the future?