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"
--
Dmitry Makovey
Web Systems Administrator
Athabasca University
(780) 675-6245
---
Confidence is what you have before you understand the problem
Woody Allen
When in trouble when in doubt run in circles scream and shout
http://www.wordwizard.com/phpbb3/viewtopic.php?f=16&t=19330
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
