Continue supporting server-side SELinux labeling

[jlebon]

We've now moved to client-side SELinux labeling. I think we should still though support server-side labeling, I guess through ostree container commit/bootc build commit? I think this today though conflicts with wanting to move away from /ostree in the container image, but it could be implemented differently of course.

The main argument is simply reproducibility. Notably, coreos/fedora-coreos-tracker#2030 happened which is a great example of why doing this server-side would be better for those that want to opt in (like FCOS/RHCOS).

[cgwalters]

This also came up in ostreedev/ostree#3523 (comment)

I think this today though conflicts with wanting to move away from /ostree in the container image, but it could be implemented differently of course.

Yes though the other obvious implementation is to just support having security.selinux xattrs in the tar stream. This would need some validation that it doesn't break/conflict with container runtimes though.

[jlebon]

Yes OK, definitely quite surprising I think that even just encapsulated commits still get relabeled (coreos/fedora-coreos-tracker#2030 (comment)).

And in the new buildah path, while we do generate an OSTree commit as part of build-chunked-oci, I tend not to think of it that way and I'm not sure if it's where relabeling should happen. E.g. what I initially had in mind for this issue is something applicable to both FROM scratch flows and simple derivations.