search

ostreedev / ostree-rs-ext

Rust library with higher level APIs on top of the core ostree API
Apache License 2.0
76 stars 25 forks source link

container commit: Actually do build-time commits #388

Open cgwalters opened 1 year ago

cgwalters commented 1 year ago

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 https://github.com/ostreedev/ostree-rs-ext/issues/159

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 commented 11 months ago

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 commented 4 months ago

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 commented 4 months ago

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

https://github.com/ostreedev/ostree-rs-ext/blob/9a4743a657ffe0435018d9720c6df80a486ca0f1/lib/src/container/store.rs#L827

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:

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 https://github.com/ostreedev/ostree/issues/3198

cgwalters commented 4 months ago

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

cgwalters commented 3 months ago

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.