extended attributes discarded for layered changes

[cgwalters]

Right now when we filter the tar stream we end up discarding xattrs - there's a bit of nontrivial work necessary on our side to handle this.

It also opens up the interesting question of whether we try to e.g. honor any security.selinux that may be present.

It is clear that we definitely want security.capability, and for that matter we might as well propagate things like user..

[antheas]

Here is a workaround required due to this at the moment. Since bazzite is using rechunk this can be removed, but it is used throughout Universal Blue images and derivatives. For other applications as well.

https://github.com/ublue-os/bazzite/blob/9a9a4861b025f44aaf6cd40ff006c911fa3abe01/system_files/desktop/shared/usr/lib/systemd/system/gamescope-workaround.service

I was told this might be corrupting OSTree file hashes, and might be partially behind secureblue/secureblue#369 which fails when setting xattrs. Or at least the variant used there, since the only 5 files that error during ostree fsck in the secureboot family have had their caps modded.

[ggiguash]

@cgwalters , the mentioned workaround is for an executable on the host file system.

If we know that we "lost" a capability in an executable inside a given image, is there a better way to set it rather than the following?

setcap 'cap_net_bind_service=+ep' ./vfs/dir/3f9f2616036a52ed598e7c806953ce61e0569a62429ab0080c46f78eea5faba3/usr/sbin/haproxy

[cgwalters]

(edited) There's no trivial build-time workaround for this possible, the xattrs are being discarded on the client side.

What would fix it is "rechunking" an image and generating an ostree commit, which we're working on tooling for, but is more invasive.