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

Ignore EPERM when setting IMA signature xattr #3516

Merged
merged 3 commits into from
Jan 13, 2025

Conversation

pmatilai
Copy link
Member

This lets installations succeed even if the ima plugin happens to be installed in a container, where IMA isn't supported. We don't know it failure was because of a container so this is far from ideal, but failing an install just because some package dragged in the ima plugin as a dependency is worse.

Counter-intuitively, the test verifies that the IMA xattr didn't get installed because that's the expected result, when inside a container.

Fixes: #3234

The first commits are tweaks to a couple of small issues I ran into when looking at this.

@pmatilai pmatilai requested a review from a team as a code owner January 10, 2025 14:25
@pmatilai pmatilai requested review from ffesti and removed request for a team January 10, 2025 14:25
Copy link
Contributor

@ffesti ffesti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Test suite fails

@pmatilai
Copy link
Member Author

Yes, I can see that 😄

Commit f7142bf placed the test into
the --delsign test group which is a very specific thing, and doesn't
actually need rpm to be built with IMA to work. Attempting to sign
always does.
"file" is not a very meaningful keyword here, "ima" lets us test just
these when we need to.
@pmatilai
Copy link
Member Author

Seems the result depends on the kind of container we have: in my local rootless container setting the IMA fails, but in the GH runner matryoshka we're actually root on the VM, the container is privileged and you apparanly can set IMA from inside. Lets see...

@pmatilai pmatilai force-pushed the ima-perm branch 3 times, most recently from 7bf194e to 5c97106 Compare January 13, 2025 09:39
This lets installations succeed even if the ima plugin happens to be
installed in a rootless container, where IMA isn't supported. We can't
specifically test for rootless container, but I don't know what other
situation would result in EPERM for root when setting IMA so it seems
like a reasonable heuristic for this.

Testing this is a bit tricky: we expect the install to succeed in all cases,
but whether IMA actually gets set depends on the container.

Fixes: rpm-software-management#3234
@pmatilai
Copy link
Member Author

Finally! 😆

@ffesti ffesti merged commit 105c5e8 into rpm-software-management:master Jan 13, 2025
1 check passed
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

Successfully merging this pull request may close these issues.

Gracefully handle plugin operations not permitted in containers
2 participants