Hide Forgot
Description of problem: rpm 4.4.5 has broken SELinux context verification, because every file/directory of the package is prompted when using "rpm -V package". When downgrading to rpm 4.4.2 from Rawhide for example, the problem disappears. SQLite support was disabled, but this shouldn't hurt in this case. Version-Release number of selected component (if applicable): rpm-4.4.5-1 How reproducible: Everytime, just upgrade to 4.4.5 and do "rpm -V rpm" or similar. Expected results: Working SELinux context verification ;-) Additional info: The product FC is maybe the wrong one, but I still hope, that Fedora Core gets closer to upstream after FC5 is released and as long as there is no product in Bugzilla for rpm, this looks the right place for me for this bug report.
Adding Stephen to avoid the total communication breakdown between rpm devel and the SELinux devel folks as already mentioned in bug #175557. Jeff favorites "SELinux out of rpm using dlopen" instead of the current solution (see MLS patch in latest Rawhide rpm version). "The ABI issues wrto libselinux are extremely hard to deal with in a statically linked binary that noone is upgrading. Deeper than ABI, MLS is semantic change to type set by libselinux." Stephen, any chance to get this soon solved in a sane way Jeff likes? If my C knowledge would be good enough, I already would have written what is needed for *enthusiastic is*.
Not sure what is referenced by 'MLS patch in latest Rawhide rpm version'. I see two SELinux-related patches in current Fedora CVS devel tree: 1) rpm-4.4.2-contextverify.patch (which appears to just be an issue of copying the context and for some reason adds guards to the freecon() calls, even though freecon() just calls free() and free(NULL) is ok), 2) rpm-4.4.2-matchpathcon.patch (which is the change to rpm to call matchpathcon to obtain the context to apply to a file rather than internally duplicating the setfiles logic). The latter one in particular is a natural step in de-coupling SELinux from rpm by moving SELinux-specific logic out of rpm into libselinux. rpm shouldn't care about MLS or no MLS; it just gets the contexts to apply from matchpathcon as complete strings and feeds them to lsetfilecon, and never needs to care whether the context has a MLS component or not. And even in the static case, libselinux determines whether MLS is enabled at runtime based on the kernel's /selinux/mls value, so it adapts as appropriate. I don't really understand why the matchpathcon changes never went upstream in rpm; no one ever came back and said "This can't be done because X, Y, and Z". We can't fix it if we don't know it is broken, and the rpm SELinux integration has been handled by Red Hat anyway - we never wrote those patches for rpm, just the library side of the interfaces.
The matchpathcon patch was not integrated into rpm because it broke the ability to buildusing --disable-selinux. This info was delivered several times. The other patch was critiqued here in bugzilla. Static binaries that link selinux *must* be upgraded when libselinux is modified in order to see deeper changes like MLS. And those selinux changes must be reflected into rpm packaging with conflicts (and more) in order to establish which versions of rpm interoperate with which features of libselinux. That is not as simple as checking the value of /proc/mls at runtime. Another issue is Why is it rpm's role to verify file contexts? And how is that verification to be done meaningfully if the answer depends on other obscure features like /proc/mls or whatevere data matchpathcon uses is being set correctly?
Ping? Maybe a bit off-topic, maybe not: WTF does /sbin/mcstransd from the mcstrans package do except consuming (wasting seems more suitable for me) lots of CPU time all the time (around 7% of CPU)? Hopefully that crazy CPU-wasting daemon "mcstransd" isn't that useless it currently looks like and is doing something useful, for example labeling and verifying files and directories using the "SELinux policy of the day". But the daemon isn't doing such a useful thing, right? Corrections are always cheerfully accepted, of course. Guessing, it's another new stuff out of the "SELinux of the day"-box jbj already mentioned in IRC ;-)
rpm-4.4.7 no longer verifies selinux file contexts.