[Apparmor-dev] Re: Disable profiles with dpkg-old, dpkg-new extension and linked from disable dir.

[Steve Beattie]

Hey Mathias,

On Mon, Aug 13, 2007 at 03:50:36PM -0600, Dominic Reynolds wrote:
> +++ Mathias Gug [13/08/07 16:12 -0400]:
> > I've attached a patch that adds profiles that should not be loaded:
> >  * files with dpkg-new, dpkg-old suffix.
> >  * files which have a link in /etc/apparmor.d/disable/.

I've committed the dpkg suffix change, along with reminder comments to
note that both the initscript and SubDomain.pm need to be kept in sync.

I'm less enthused about the latter change; I understand the desire for it.
I don't like this particular approach because it means an admin needs
to check in two locations to see if there's a profile and it's not
disabled. Another aspect is that, other than knowing to skip the disabled
profiles, the tools have no knowledge of them and to potentially use
them as a starting point if an admin decides they do want to profile
that particular application.

I'd rather see the community standardize on a mechanism for
enabling/disabling profiles, one that involves looking one place only
to determine what profiles are enabled.  (Admittedly, gui tools could
do a better job of presenting this information.)

> I'm working on a spec (to be posted to apparmor-dev soon) for discussion
> about some changes to the profile layout to allow multiple repositories of
> profiles (local and remote) so that multiple copies of a profile may be
> available locally, and so that profiles can be stored locally but inactive or 
> disabled.

As I understand what I've seen of your proposal, the idea is also
that distributor provided profiles would get installed outside of the
"enabled" location so that admins can more easily separate out their
changes from distribution updates (and distribution updates won't affect
edited profiles or re-enable removed profiles; more of an rpm problem
than a dpkg problem, I think). Simple tools could be provided for use
in the post-installation phase to enable (or disable) specific profiles,
a la SysV initscripts.

Dom, can you post your proposal?


-- 
Steve Beattie
SUSE Labs, Novell Inc. 
<sbeattie at suse.de>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-dev/attachments/20070814/47af87b9/attachment.pgp