RPM

RFE: add --setfscontext popt alias to rpm

Bug #660406 reported by devzero2000
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
RPM
Fix Committed
Wishlist
devzero2000

Bug Description

rpm alias has the following popt alias

- setperms
- setugids

to reset the permissions on the files included in a rpm package. But i a selinux system rpm includes also the selinux file context, so seems right that there is a equivalent (for simmetry) popt alias as

- setfscontext

to restore the selinux file context files that context, without necessarily having to use an external utilty to rpm as fixfiles (with fixfiles -R rpmpackagename)

Tags: selinux
devzero2000 (pinto-elia)
Changed in rpm:
status: New → Fix Committed
Revision history for this message
Jeff Johnson (n3npq) wrote :

(my offhand comment to the commit ... the commit is perfectly fine)

Ick ... but adding --setfscontext as an alias is exactly the right approach.

My "Ick" has more to do with the fact that SELinux has flat zippo to do
with "packaging", and the RPM CLI has all sorts of other issues rather
than adding --setfscontext smoke and mirrors alternative to invoking
/sbin/restorecon. OTOH, hurts nothing at all.

I have exactly the same "Ick" opinion wrto recent changes @rpm.org to split
package signing into a separate "rpmsign" executable, and then adding popt aliases
to pass ooptions from "rpmsign" to gpg; I'm just not sure what purpose is
being served.

Meanwhile its utterly trivial to add/delete popt aliases to extend RPM functionality.
My "ick" here is largely from experience with meeting expectations: there's only so
much info and functionality that can be hidden behind an option. Precise/specific
behavior needs a better programming paradigm than pipe fitting.

Revision history for this message
Jeff Johnson (n3npq) wrote :

I should make the connection between rpmsign and --setfscontext clearer.

One of the reasons for splitting package signing into a separate rpmsign executable
is to avoid adding a
    Requires: /usr/bin/gpg
or
    Requires: /usr/bin/gpg2
dependency to RPM's packaging. There's a macro with a default value that controls
which executable to invoke.

Prelink has a similar attachment to RPM behavior, there's an implicit pre-requsite
onto prelink(8).

There is a similar luser expectation for --setfscontext, which has an implicit/ovious
pre-requisite of
   Requires: /sbin/restorecon
as for gpg/gpg2/prelink.

There's no one right/clear/consistent answer ... so please don't take my comments
as being against --setfscontext.

Revision history for this message
Jeff Johnson (n3npq) wrote :

One last comment, more as an aside to --setfscontext expectations
than anything else ...

There is a way to track implicit dependencies on helper executables
using probe dependencies. E.g. RPM packaging SHOULD carry
    Requires: executable(/sbin/restorecon)
or (for path relocation independence portability, note the doubled percent)
    Requires: executable(%%{_sbindir}/restorecon)
or (to use PATH lookup instead, with the obvious change to the alias)
    Requires: executable(restorecon)

And if one wants to make the dependency "soft", and treat the dependency assertion
failure as a warning rather than an error
    Requires(hint): executable(restorecon)

Revision history for this message
devzero2000 (pinto-elia) wrote :

Ok. I mostly agreed with your (interesting) comment. Anyway the little toy popt alias don't require strictly that restorecon exists. But yes, I will make further investigations on this subject.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.