Red Hat Bugzilla – Bug 824799
add macro for SELinux labels
Last modified: 2016-11-24 08:04:35 EST
Uh, how did this get assigned to me? I have nothing to do with SELinux
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.
*** Bug 879168 has been marked as a duplicate of this bug. ***
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.
(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?
(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.
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.
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.
(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).
Making public & moving to Fedora
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:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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'
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.