Drop overlay attributes before creating squashfs.

[smoser]

The overlay attributes [1] have given us some grief [2]. They don't seem to provide benefit. We are keeping the overlay.opaque values, but drop everything else in .overlay. namespace.

[1] https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html
[2] vasi/squashfuse#78

[hallyn]

Should the trusted.overlay.opaque xattrs be renamed to user.overlay.opaque?

[smoser]

Should the trusted.overlay.opaque xattrs be renamed to user.overlay.opaque?

It feels to me like that should be a mount time thing, rather than a fs-create time thing. The only thing that I see about 'trusted.overlay' vs 'user.overlay' namespace is from kernel overlay doc .:

The “-o userxattr” mount option forces overlayfs to use the “user.overlay.” xattr namespace instead of “trusted.overlay.”. This is useful for unprivileged mounting of overlayfs.

What do you think, am I missing something? Suggesting that I should modify the creation of a filesystem to account for unpriviledged mounts seems somewhat like suggesting I should shift all my UIDs by 65535 so that a usernamespace would have the right uid/gid mappings. it seems not the right place to do it.

It is absolutely p ossible I'm missing something.

[hallyn]

So actually we shouldn't need to do a post-build step, we should be able to just mount over build overlays with the ,userxattr option.

Regarding a mount option - how would it work? Would it be an overlay mount option which says "when copying up a file that has a trusted.overlay xattr, ignore that xattr"?

[hallyn]

I opened #323 - I'm fuzzy on whether that would be a replacement or an enhancement to this PR. I'm thinking replacement right now. What do you think?

Confirmed with a toy busybox based local testcase that i now get user xattr:

$ ~/test/llistxattrfull /mnt/a
ret 20 on /mnt/a
nret 20 list user.overlay.origin

[smoser]

So actually we shouldn't need to do a post-build step, we should be able to just mount over build overlays with the ,userxattr option.

Regarding a mount option - how would it work? Would it be an overlay mount option which says "when copying up a file that has a trusted.overlay xattr, ignore that xattr"?

Isn't that what "-o userxattr does" ?

[hallyn]

So actually we shouldn't need to do a post-build step, we should be able to just mount over build overlays with the ,userxattr option.
Regarding a mount option - how would it work? Would it be an overlay mount option which says "when copying up a file that has a trusted.overlay xattr, ignore that xattr"?

Isn't that what "-o userxattr does" ?

No. -o userxattr will create new xattrs are user., but I don't believe it will prevent breakage if you try to copy up a file from an underlaying fs which has a trusted.overlay. xattr.

[hallyn]

So, do we still want this patch, @smoser ? (Last night I was thinking no, but now I'm thinking yes.)

[smoser]

So, do we still want this patch, @smoser ? (Last night I was thinking no, but now I'm thinking yes.)

well, it solves the problem for the (we think) buggy kernel on our jenkins.