I'll just reply to both Dominick and mark below in one swift shot:
On February 2, 2012 15:19:15 m.roth@5-cent.us 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"