Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

container commit: Actually do build-time commits #388

Open
cgwalters opened this issue Oct 20, 2022 · 5 comments
Open

container commit: Actually do build-time commits #388

cgwalters opened this issue Oct 20, 2022 · 5 comments

Comments

@cgwalters
Copy link
Member

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
Copy link

plata commented Nov 1, 2023

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
Copy link
Contributor

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
Copy link
Member Author

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

// 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
Copy link
Member Author

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants