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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
