Hello,
Am Donnerstag, 13. Oktober 2016, 07:25:56 CEST schrieb John Johansen:
> On 10/12/2016 02:55 PM, Christian Boltz wrote:
> > Am Mittwoch, 12. Oktober 2016, 14:31:13 CEST schrieb John Johansen:
> > ...
> >
> >> atm I think I am in favor of wrapping it in the conditional and
> >> defaulting that conditional to false.
> >>
> >> The ubuntu patch then changing the conditional to true. This way
> >> the information is being carried upstream. And only the distro
> >> specific tweak is out of tree.
> >
> > That sounds like a good idea, but... -
...
> > So if you add any boolean condition, expect aa-logprof etc. to break
> > completely :-/
> >
> > I'm aware of this since I wrote the test that checks against
> > simple_tests, but it has low priority because nobody seems to use
> > conditionals in practise. At least I never received a bugreport ;-)
> >
> > Unfortunately fixing this isn't easy - the tools will probably need
> > to handle a "stack" of parenthesis ("I'm inside 'if $foo'") or
> > something like that. (Besides conditionals, that stack should also
> > handle owner { } and audit { } blocks, and also nested child
> > profiles.)
> >
> > To make things even worse, this major code change will probably have
> > to happen in an area of aa.py which is hard to cover with unit
> > tests.
> well we are going to have to start fixing this, our plans for policy
> versioning and "support" of new features on old parsers rely on
> boolean conditional support
I won't object ;-) and it is something I have on my TODO list.
However, I'm afraid such a change _will_ break something (again - this
will happen in code that is hard to cover by unittests), so we should do
it _after_ the 2.11 release to only break it for people like us who use
the bzr version.
That said - I'd like to have support for nested child profiles first,
because that will also need the parenthesis stack. Supporting
conditionals first means we'd need to check if we are in the conditional
stack or "just" at the end of a profile or child profile, which probably
makes the code even more complex.
To support nested child profiles, we'll also need a change from
aa[profile][hat] to a flat structure like aa[full_profile_name].
include[include][include] will also need to be flattened.
While doing this, we can (and should!) change 'aa' and 'include' from
hasher to dict, which will probably uncover some funny[tm] things we
didn't notice yet.
Oh, and it would be even better to have all stateful storage inside a
class so that we can get rid of reset_aa() in aa-mergeprof and just
create another instance.
Sorry for this long dependency chain ;-)
TL;DR: There's lots of fun (and fun[tm]) ahead!
If someone has time to start working on this - help is more than
welcome ;-)
> > For now, a possible workaround could be to abuse variables. The
> > upstream code could have something like
> >
> > @{RESOLVED_DBUS_SOCKET}=""
> >
> > and Ubuntu could set it to the real dbus socket. I know this is ugly
> > (and it also means not to use abstractions/dbus-strict), but it's
> > still better than breaking all aa-* tools.
>
> I'd rather not do this
There's a reason why the description of this workaround contains the
word "ugly", so I'm not surprised ;-)
Regards,
Christian Boltz
--
Ich habe sogar schon den passenden Werbespruch für suse-announce:
*Nicht nur sauber sondern rein: Mails gewaschen und gebügelt mit t-prot!
Noch nie war Mega-Perl so saugstark!!!* [Jan Trippler in suse-linux]
signature.asc
Description: This is a digitally signed message part.
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
