Red Hat Bugzilla – Bug 182998
rpm 4.4.7 has broken SELinux context verification
Last modified: 2007-11-30 17:11:25 EST
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):
Everytime, just upgrade to 4.4.5 and do "rpm -V rpm" or similar.
Working SELinux context verification ;-)
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
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
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
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.