container commit: Actually do build-time commits

[cgwalters]

We added support for RUN ostree container commit, but today it only does some basics like validating compatibility with /var etc.

This issue tracks changing that to implement what was talked about in #159

• Perform selinux labeling
• Compute ostree sha256

etc. And related to this, we should be sure to use the SELinux policy from the current layer (specifically any modifications done via semanage fcontext).

[plata]

Until this is implemented: Is there some way to detect that there will be a problem at build time and warn about it? Currently, it just silently leaves you with broken SELinux labels which cause issues at runtime which is not exactly optimal.

[jeamland]

Hi! I'm wondering what the status of this is and, if the status is "it's stalled" then what would be a good place to start working on it.

For context, we have an internal effort that's building an image using rpm-ostree but where we have some use cases that require customisation and to streamline that our notion was to allow teams to take our base image as a container, customise it using normal container build mechanics, and then we'd ingest the result back in to a branch within the same central ostree repo that we're keeping the base image in.

What I ran into with this is that the selinux labels appear to get messed up when the container build does it's thing, which is what led me here.

If my understanding is correct one way to address this would be for ostree container commit to relabel things as per the policy contained in the base image. Does that sound accurate?

[cgwalters]

I think we just need to change the way this project handles labeling by default, it's around here:

ostree-rs-ext/lib/src/container/store.rs

Line 827 in 9a4743a

// First download all layers for the base image (if necessary) - we need the SELinux policy

Ultimately...we could make a lot of this a lot more efficient if we could hard require composefs, because that allows us to only put the labels in the composefs metadata, leaving the underlying files as raw data blobs. The thing that's very inefficient with "plain ostree" in this respect is how the selinux xattrs are part of the object hash (because it's all about hardlinks), which means changing them recomputes that hash.

But, short term I think we can just change things to:

• check out final squashed tree
• compute labels
• commit

A challenge here is that while composefs for the host works, in order for us to pull off a full hard switch by default we need to fix things like ostreedev/ostree#3198

[cgwalters]

Also hi @jeamland - good to see you again 😄 If you want to do any work in this area, I'm happy to help and discuss it!

[cgwalters]

OK @travier convinced me that it's probably worth a spike on having RUN ostree container commit work. Just thinking through this...we are likely to end up in a situation where we duplicate some content across layers though, unless we try to carefully detect that somehow.