Bug 824799 - add macro for SELinux labels
add macro for SELinux labels
Status: NEW
Product: Fedora
Classification: Fedora
Component: scl-utils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Panu Matilainen
nobody nobody
: FutureFeature, Reopened, SELinux
: 879168 (view as bug list)
Depends On:
Blocks: 836170 965565 1071161
  Show dependency treegraph
 
Reported: 2012-05-24 05:53 EDT by Jan Kaluža
Modified: 2016-11-24 08:04 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-06 07:12:44 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 2 Andrew Beekhof 2012-05-24 20:05:10 EDT
Uh, how did this get assigned to me?  I have nothing to do with SELinux
Comment 3 RHEL Product and Program Management 2012-05-30 01:47:38 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 6 Jan Zeleny 2012-11-22 04:34:34 EST
*** Bug 879168 has been marked as a duplicate of this bug. ***
Comment 8 RHEL Product and Program Management 2013-10-14 00:59:12 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 9 Vít Ondruch 2014-03-04 07:02:21 EST
Not sure why the original subject was changed, but I'd rather see SELinux labels set up properly without any additional macros. Macros should be used just for fine tuning and special cases. The root FS should have proper labels out of the box, without any explicit action.
Comment 10 Jan Zeleny 2014-03-04 07:08:24 EST
(In reply to Vít Ondruch from comment #9)
> Not sure why the original subject was changed, but I'd rather see SELinux
> labels set up properly without any additional macros. Macros should be used
> just for fine tuning and special cases. The root FS should have proper
> labels out of the box, without any explicit action.

But that doesn't sound like an issue of scl-utils. That's more related to selinux-policy, isn't it?
Comment 11 Vít Ondruch 2014-03-04 07:21:29 EST
(In reply to Jan Zeleny from comment #10)
scl-utils creates the root FS. From that POV scl-utils should ensure correct SELinux labels. If you think that selinux-policy should be adjusted, it is perfectly fine with me and I am happy you are going to collaborate with SElinux guys to narrow that. I'll be glad that I won't need to use any additional macros in my collection package to achieve that and frankly, that that is my only goal.
Comment 12 Jan Zeleny 2014-03-06 07:12:44 EST
I'm sorry but I have no idea what are you talking about. We only create the filesystem in the buildroot but then rpm packs it to the packages, that's where our role ends. Setting the right context is the job of package maintainers, as it has to be done in %post of your packages.

The way I see it we have just three options:
a) document what commands should be run in %post and leave it up to maintainers to decide if they need to run them or not (that's the current state)

b) provide a macro that the maintainers will use in the %post scriptlet instead of the two commands (only a cosmetic change, does not really improve anything)

c) Extend selinux-policy to include policies for chroot environments in /opt/rh/*/root (at this point I don't think that's possible but we can try)

If you have any other concrete ideas, I invite you to come forth. One option would be to automatically generate the %post scriptlets entirely but that's way out of scope of scl-utils.

Since you clearly expressed the only solution you consider acceptable and I don't see a way to implement such a solution, I'm closing the bug. If you find any feasible solution, feel free to reopen.
Comment 13 Vít Ondruch 2014-03-06 07:31:31 EST
Jan, I am seeking for every possible solution, where as less as I must do on my side is the best option, since it prohibits possible omissions on maintainer side. Also, if it is later discovered that something is wrong, fix in scl-utils is enough (possibly accompanied by metapackage rebuild). This way, we do not reintroduce old errors into new SCLs, etc.

Please, adopt this view and investigate at least b or c. a is as always the last possible option, if other option fails.

Thank you.
Comment 14 Jan Zeleny 2014-03-06 07:57:39 EST
(In reply to Vít Ondruch from comment #13)
> Jan, I am seeking for every possible solution, where as less as I must do on
> my side is the best option, since it prohibits possible omissions on
> maintainer side. Also, if it is later discovered that something is wrong,
> fix in scl-utils is enough (possibly accompanied by metapackage rebuild).
> This way, we do not reintroduce old errors into new SCLs, etc.
> 
> Please, adopt this view and investigate at least b or c. a is as always the
> last possible option, if other option fails.

I'm confused. Is b) really enough for you? It would be just an alias and you would still have to add the macro to the spec file manually (which you clearly refused to do in comment 11).
Comment 15 Jan Zeleny 2014-04-08 07:41:49 EDT
Making public & moving to Fedora
Comment 16 Jan Zeleny 2014-04-08 07:43:18 EDT
Upstream ticket:
https://fedorahosted.org/SoftwareCollections/ticket/7
Comment 17 Jan Kurik 2015-07-15 11:08:36 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 18 Fedora Admin XMLRPC Client 2016-05-30 10:59:04 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 20 Fedora Admin XMLRPC Client 2016-10-12 04:02:23 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 21 Fedora End Of Life 2016-11-24 05:39:35 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

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