[DSE-Dev] How to package policy?
Erich Schubert
erich at debian.org
Mon Mar 13 00:23:31 UTC 2006
Hi Thomas,
> I thought debconf allowed for multiple checkboxes like:
> [ ] policy for the apache webserver
> [x] policy for inetd
> [x] policy for the cups daemon
> ... and so on.
Which makes it hard to add proper dependency handling, or to show hints
to the user which stuff was autodetected. Especially on upgrades it
might be nice to be able to see which policy files are new, etc.
> Yeah, I hope this will get better in the future. It's also worth
> pointing out that the interfaces are just a (good) convention, they are
> not enforced, so if you write local policy for yourself and you don't
> want to upstream it you can use types as you wish, without any
> interfaces.
Yes, and people should be aware that afaict interfaces are "evaluated"
at build time of the using module. So if you modify an interface, you
actually have to rebuild/upgrade all modules that use it.
> Isn't this just a fixable bug in APT? Fixing it won't help us for Sarge
> of course, but at least we could then provide such packages for Etch
> (and maybe Dapper).
Agreed that this limitation is a bug of APT, but in my opinion we should
encourage users to develop their own policy modifications in their home
directory, and then use e.g. meld to merge changes when they obtain a
new upstream version.
dpkg magic with .dpkg-old and such won't ensure your policy remains
compileable, all it will make sure is that you don't lose your
modifications (which it doesn't for /usr/share/selinux, but people
should IMHO keep around an unmodified copy for reference anyway...)
> > In our current setup they can be installed alongside with each other,
> > and I think that works okay.
>
> Hmm, I haven't really looked at this yet. If both are installed, how do
> we decide if we should reload policy on an upgrade? Should this be
> another debconf question?
Either a question or not change anything by default. Build/load a policy
on a fresh install with no other policy installed yet, don't do anything
otherwise.
The risk of breaking stuff is quite high...
Oh, and especially for the source case we shouldn't build any policy,
the source is for people who want to modify it. the others should just
use the compiled.
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org) -- GPG Key ID: 4B3A135C (o_
To be trusted is a greater complement than to be loved. //\
Denken ist oft schwerer, als man denkt. V_/_
More information about the SELinux-devel
mailing list