[apparmor] Packaging of Profiles

[John Johansen]

On 08/10/2010 04:32 AM, Seth Arnold wrote:
> " do not agree. This is not 'breakage'. One, there shouldn't that many
> people affected if the policy is good enough and two, the user will get
> prompted on upgrade, yes, but upgrades happen seldom for regular users."
> 
> You must not have local changes in your firefox config. :)
> 
I really don't think you are one of the regular users that Jamie is
referring too.

> Try this experiment: take an older firefox install, and modify the
> profile to forbid all Ux access. Remove all the text-editor business.
> Remove the mail and terminal business. Confine flash. (60÷ of why
> firefox needs a profile in the first place.) Then upgrade firefox through
> three or four versions, trying to keep things tight while still
> integrating changes for e.g. Openjdk and sun jre.
> 
yes this is a nightmare, and one of the situations we need to improve

> You'll probably get tired of reading a ~sixty-line diff to find the one
> change in the profile. And you'll probably want a three-way merge to
> show you only what changed in the most recent upgrade, not where the
> profile differs from your existing profile.
> 
or at least of three way diff.  This is one of the situations where the
simplistic two way diff fails.

> Honestly, I'd be happy if I could easily tell dpkg to never write into
> /etc/apparmor.d/ and put the updated profiles in /usr/lib/ somewhere.
> I guess I could take the time to learn how to modify my dpkg-config
> settings to always prefer my files, and just clean up all the .dpkg-new
> files periodically, but I can't be the only one annoyed at
> distro-provided profile updates.
> 
You aren't.  They annoy me and I have heard from several people over the
years who have had issues.

> We tried something isomorphic to the local/ directory a few years ago,
> and hated it. It was my idea, my implementation, and I came to detest it.
> 
I remember this all to well

> I don't want another band-aid. Your profiles make sense for the
> distribution as a whole: they are safer than nothing, but not tight
> enough for me, not even close. But I still want to see what's new
> in your profiles.
> 
yep.  Though sadly atm your experience isn't going to improve, at least
not until I get a mythical merge tool developed.

> Hence, storing profiles in /usr/lib, copying them over when a user wants
> one, and 3-way merging with them. Much nicer.
while I agree, I think we need to get that merge tool first.  I think
I can envision ways to lay the ground work for that future without
changing the current experience, but I am going to have to differ to
the packaging experts (something I am not).

> New porcelain over git for apparmor.d also seems like a much nicer
> profile repository implementation, it could be leveraged for distro
> updates too, but I 100÷ agree on VCS-in-VCS hell avoidance.
> 
yes git would be better than the current repository, and we need to
get a discussion going of where we are going there.  I see it as
a separate issue however and was merely musing on how it could integrate
to make the potential conflicting change set even smaller.

I do agree with Jamie however that git (or equivalent) installed by
default and required as part of policy management is a none starter.