[Rpm-maint] [rpm-software-management/rpm] RFC: If existent, apply SELinux label from full non-chroot path (PR #3967)

[Cathy Hu]

ca-hu left a comment (rpm-software-management/rpm#3967)

> I'm not sure this makes sense? Maybe I'm reading this wrong, but this would result in completely breaking image builds too. 

If we stay at the original draft, it might be the case if the image build relies on rpm and rpm only to set the labels and the chroot directory is not set to `<<none>>` in the policy. I am not sure how it is done in fedora. But in openSUSE, we do a full relabel of the freshly installed file system during first boot when it was installed by rpm (except kiwi, which uses setfiles), so as far as I can see (note that I am not directly involved in image builds) it should be fine.
Or do you have a particular setup in mind?

If we do the explicit flag in rpm, I think it should be fine, because the default behaviour stays the same.

> It's not _that_ well-known, but it is possible to apply SELinux labels from an on-disk policy to files. We do this in kiwi using `setfiles`, as an example:
> 
> https://github.com/OSInside/kiwi/blob/ae738e396985d6841a738772c5f77e56f8f4702a/kiwi/system/setup.py#L605-L612
> 
> I don't think it would be reasonable for RPM to do anything different. What we don't have in SELinux tooling is a way to easily and automatically figure this out (we make educated guesses with kiwi and hope for the best), but that's probably something for SELinux people to help with.

Not sure if I understand correctly, but the rpm selinux plugin is setting the labels from a policy ATM but just via the SELinux library instead of relying on the existence of setfiles. Not sure how using setfiles explicitly would make things better?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3967#issuecomment-3965192395
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/3967/c3965192395 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260226/41a28e45/attachment.htm>