Bug 175557

FYI: SELinux support is headed out of rpm because there is
essentially no communication between different devel efforts,
and SELinux and rpm have drastically different goals.

Why can't SELinux figure out how to write
    system_u:object_r:texrel_shlib_t
to the file file_contexts.local?

Don't almost all DSO's have text relocations? Perhaps the problem is
easier to solve for the handful of DSO's that don't have text relocations.

> Why can't SELinux figure out how to write [...]

This makes no sense, there is no SELinux program which can figure something out.
 ALl changes to security contexts must be initiated by somebody.  One could have
cron jobs going over the entire filesystem space every minute to detect new
files but this is insane.  The context must be set correctly at installation
time and this means rpm.


> Don't almost all DSO's have text relocations?

Hell, no.  Almost none has and the recent policy changes will hpefully abolish
almost all the remaining ones.


I won't comment on the first paragraph since I have no idea what "rpm" you're
talking about.  The rpm in Red Hat's distributions definitely needs SELinux
support and this request is solely directed to the rpm Red Hat ships.  I could
not possibly care less about the "upstream" version.

I don't know about communication breakdowns between rpm devel and SELinux devel
folks; if we've erred, let us know and we'll try to improve.  Doesn't help to
carp about it in a bugzilla entry that few people will ever see.  Wandering over
to the rpm devel list archives, I see that you've proposed further separation
there, but I'm not clear that will actually help - ultimately, package
management has to be aware of and properly integrated with SELinux, and making
it easier for us to break one another without coordination doesn't seem to help.

On this particular issue, rpm currently handles setting the security context on
files when they are installed from packages, so it seems to make sense for rpm
to invoke some functionality for checking whether a DSO it is about to install
has text relocations and to then invoke some SELinux function (likely some new
libsemanage interface) with the file's installation pathname and the result of
the text relocation test so that the file contexts configuration can be updated
properly.  Then when rpm calls matchpathcon to get the context to apply to the
installed file, it will get the proper context, and any subsequent restorecon,
setfiles, etc runs will properly preserve it.  The details of updating
file_contexts.local would be encapsulated in some SELinux function, as you suggest.

  

The issue is tying package management to dynamic configuration. this leads to hard QA
and many erroneous bug reports, mostly due to slowly changing policy deploy.

Adding New Stuff (like this RFE) creates instant (and difficult) legacy. rpm essentially
cannot be upgraded because noone is making the effort, and no vendor is willing to
undertake the retrofit.

So all I can see is to freeze in the existing hooks, and split out into a dlopen package that
might be changed more rapidly than rpm is.

Meanwhile -- if you wish my help -- rpm-devel.duke.edu is the place, as clearly
this is Red Hat's, not rpm's, bugzilla now.

And for Yet Another Conundrum, /bin/rpm is now statically linked again again again, so dlopen
of libselinux appears only viable approach other than reverting to dynamically linked.

... if there is still interest in this bug, libsemanage now has the capability
of adding new file contexts programmatically (semanage/fcontext_*.h). An
semanage transaction is rather slow, so the way to handle this is to start a
transaction, deal with all relocations for multiple rpms, then commit (not per
rpm). 

There certainly is the need to do this.  There will always be code with text
relocations on some systems, regardless of how hard we try to remove them. 
Proprietary software (including the nvidia GL libraries) are beyond our control
but have text relocs.

So, adding this code certainly makes sense.

The issue is adding the code to rpm, not whether there is a need to add code to support a given 
functionality.

NEEDINFO_ENG so I don't have to stare at the bug.

NEEDINFO_ENG has been deprecated in favor of NEEDINFO or ASSIGNED. Changing
status to ASSIGNED for ENG review.

The right way to fix this problem (per my sense of discussion w smalley and drepper @ OLS) is
for rpm to provide the infomation that a file has text relocations to libselinux so that a different
security context can be attached to the file.

Some means of passing the information to libselinux needs to be devised.

The wrong way to fix this problem is to have rpm with a compiled in rule to change what contexts that
libselinux returns.

User pnasrat's account has been closed

Reassigning to owner after bugzilla made a mess, sorry about the noise...

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This is ancient! Does anyone still care? Does the problem even exist any more? Please reopen if that's the case.