Bug 182998 - rpm 4.4.7 has broken SELinux context verification
rpm 4.4.7 has broken SELinux context verification
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-24 21:16 EST by Robert Scheck
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-07 17:12:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2006-02-24 21:16:50 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):
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.
Comment 1 Robert Scheck 2006-03-03 11:48:37 EST
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*.
Comment 2 Stephen Smalley 2006-03-06 09:32:16 EST
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.
Comment 3 Jeff Johnson 2006-03-06 10:51:11 EST
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?
Comment 4 Robert Scheck 2006-05-21 08:15:10 EDT
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 ;-)
Comment 5 Jeff Johnson 2006-07-07 17:12:55 EDT
rpm-4.4.7 no longer verifies selinux file contexts.

Note You need to log in before you can comment on or make changes to this bug.