On 6/15/18 8:05 PM, John Johansen wrote:
On 06/15/2018 09:36 AM, Vincas Dargis wrote:
On 6/14/18 10:22 PM, Jamie Strandboge wrote:
Your idea about apparmor/2.13,
apparmor/2.12 is interesting. I suspect there will be some duplication
there too, but I'm not terribly about it.
Yes there will be duplication for the packages that ships updates in stable
versions (like Thunderbird and Firefox), while AppArmor abstractions are not
being upgraded. That's the main point of basing on AppArmor versions - for
clearly defining available abstractions (and their update) and for policy
features/versions, that profiles depend heavily on.
So I agree that the repo should be refactored but I am not sure this
is the approach that should be taken (possibly for older policy) I
need to think about it more. With all policy becoming versioned we are
going to see a mixing of different version on the same system. We
certainly could segregate on version, making it easier to see what
hasn't been updated but then profiles that haven't been updated might
get left out and that isn't what we want either.
With policy versioning we could have single profile for all future
AppArmor releases? Basically, no more need to have these directories
(nor "ubuntu", neither "apparmor/x.y")?
Will we have new policy version numbers on every minor AppArmor release
(with new/updated abstractions)?
Could you give us an example of how versioned profile snippet will look
like? Meaning, "if apparmor/policy version is >= X, then include
<abstraction/foo>, else copy-pasted rule...".
Maybe we could still use "apparmor/3.0" directory for new-style
versioned profiles, leaving ubuntu/x.y for backpacking as it is now (We
will have Ubuntu 18.04 for quite some time). If any day policy changes
too much, "apparmor/4.0" could be added, or maybe we are sure enough
that that's never going to happen, and we don't need that "3.0" at all?
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
