[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Making Fedora a contributer friendly environment



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.

Paul.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]