On 02/02/2012 10:45 PM, Dmitry Makovey wrote:
I'll just reply to both Dominick and mark below in one swift shot:
On February 2, 2012 15:19:15 m.roth@xxxxxxxxx wrote:
I am curious: what type of stuff are you referring to when you mention
semanage?
packageA:
%post
semanage fcontext -a -t httpd_sys_content_t /webapps/appA
setsebool -P httpd_can_sendmail on
pacakgeB:
%post
semanage fcontext -a -t httpd_sys_content_t /srv/appB
setsebool -P httpd_can_sendmail on
above is a sample that is not exact, but presents situation. In both cases I
would want to clean-up after package is uninstalled to get system into the
previous state:
packageA
%postun
restorecon -R -v /webapps/appA
setsebool -P httpd_can_sendmail off
And I just "shot" packageB's requirement. Same can happen to the fcontext
stuff, just oversimplifying here. I do not feel like building meta-packages
for each statement and add dependancies, like:
httpd-sendmail-trigger.rpm:
%post
setsebool -P httpd_can_sendmail off
and make packageA and packageB:
Require: httpd-sendmail-trigger
with a bit more added complexity it's going to be hairy maintaining all the
interdependancies etc.
As for setsebool i do not see a problem with conflicts/overlap. If you
just add 'setsebool -P somebool on' in your %post if you need it to be
on then i dont see how it matters what the current value of the boolean
is.
For that matter, if packageA needs a boolean on, and packageB needs it
off, you have deeper problems that you're going to have to resolve before
you think of building packages.
see above, it's not about install time - install is actually no-problem. It's
the removal, upgrade when you need to relabel etc. Above is a very simplistic
scenario, you can add complexities like upgraded package been moved to a
different directory, while previous semanage rules overlapped on the old one,
now removing packageA would wipe all the fcontext goodness it installed there
to begin with. Kind of messy, unless I'm missing something either in RPM or
SELinux.
My current way of thinking is: build module-like infrastructure:
/etc
\_selinux.d
\_packageA
\_policy1.sh
\_packageB
\_policy1.sh
\_policy2.sh
then do something like:
$ (find /etc/selinux.d/ -type f -exec cat \{\} \; | sort -u | sh
in which case we run above whenever package is installed/remove/updated (and
subsequently structure of the above /etc/selinux.d has changed), but we need
to first: remove all existing customizations (fcontext, booleans, etc) before
launch, second: relabel everything right after - because there are going to be
leftovers from the old packages.
Problem with the above - system is going to be "broken" while relabeling and
reinstall of policies is happening. And those are not really fast processes.
Not to mention that it seems a bit "clunky" and "kludgy"
You could actually include pre-built modules with the necessary policy
in your packages, e.g. as described in:
http://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
So if package A and package B both have policy allowing something
(rather than messing with a boolean), removing one of those packages and
its policy module will still leave the other's policy module present and
hence it will still be able to do what it needed to do.
Paul.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
