Bug 182998

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.