Making Fedora a contributer friendly environment

Paul Howarth paul at
Thu May 10 15:33:33 UTC 2007

Till Maas wrote:
> On Do Mai 10 2007, Karl MacMillan wrote:
>> When selinux is turned on again a full relabel of the filesystem is done
>> to correct these problems. If the custom file context wasn't added to
>> the database of file contexts (via a module or semanage) the file is set
>> to the default label.
> So will chcon in a scriptlet work, when an rpm is installed while selinux is 
> not active?
>> Not sure what you mean - you should be able to run semanage in a post.
>> Perhaps you should also need to do chcon (as opposed to restorecon)
>> because the command may not have run before the file was created.
> When I tested semanage, the problem occured, how to update the labels with 
> semanage. E.g. when the regex is changed that desribes, which files should be 
> labeled in a certain way. And when one wants to remove the old labels when 
> uninstalling the package. E.g
> version 1 of the package:
> %post
> semanage add RULE1
> %postun
> semanage remove RULE1
> As far as I understand rpm, when updating the release of version 1, first 
> semanage add RULE1 from release two runs from %post and then
> semanage remove RULE1 from release one. This effectivly removes the rule from 
> the /etc/selinux, because identical rules seem not be added more than once 
> to /etc/selinux. When I restrict the %postun only to complete removals of the 
> package, than when one changes the RULES, e.g. in a version 2:
> %post 
> semanage add RULE2
> %postun
> semanage remove RULE2
> then RULE1 will not be removed (it is not the final remove). Then every 
> release has to include "semanage remove RULE1" in "%post" maybe forever. I 
> hope you understand the problem I try to describe, because I did not really 
> use the correct selinux-terms.
> I would be happy, if I am wrong with this. But if this problem is not solvable 
> with semanage, imho semanage is not a good way to add selinux support to a 
> package.

I agree entirely, and would advocate using a policy module instead of 
semanage, even if all the module contains are file contexts and no rules 
(you may need a dummy rule that duplicates an existing one to get the 
module to build and install properly though). Policy modules have 
versioning built in and so upgrades work as expected. It's just a lot 
more work to package them.

For simple context fixes, getting them into the main selinux-policy 
package is almost certainly the best and least hassle method though.


More information about the fedora-devel-list mailing list