[apparmor] [patch 3/5] parser - more dbus variable testcases
Steve Beattie
steve at nxnw.org
Mon Sep 9 20:39:21 UTC 2013
On Thu, Sep 05, 2013 at 02:21:33AM -0700, John Johansen wrote:
> On 09/05/2013 01:18 AM, Steve Beattie wrote:
> > This patch adds more testcases around variables used in dbus rules.
> > In particular, it
> >
> > - attempts to verify that variable expansion and alternation
> > expansion results in identical DFA blobs,
> nice, though I will add a caveat, its theoretically possible that
> we can generate an isomorph of the dfa previously produced. It will
> have the same number of states and same size but will not have
> states stored in the same order.
>
> Generally this shouldn't happen, I've tried to ensure that we are
> using stable algorithms but since we rely on the stl I can't guarentee
> it.
Yeah, I understand the caveat, and generally try to verify via
behavioral tests, but Tyler had already added the tests, so it made
sense to extend it. Longer term we can revisit it, perhaps replacing
it with something that understands the structure of the DFA blobs,
and can identify isomorphic constructions.
> > - tests that variables can be expanded within alternations,
> > - tests that alternations can occur in variable definitions, and
> > - that having alternations inside variable declarations that are
> > used inside alternations results in a parsing failure
> err this failure is a bug, we are supposed to support nested alternations
We are? We never have, looking at the code history. That said,
fixing it so that nested alternations work would be a great thing, as
this bug is one of the hurdles in converting variable expansion from
adding nearly identical entries to inline expanding into alternations,
in order to reduce the workload on the DFA generating backend.
I'll try to review the patch to allow nesting alternations today or
tomorrow.
> What about having an alternation partly defined in the variable?
>
> something like
>
> @foo=this{is,really
> @{foo},bad} r,
What about it? It currently works (or is at least parseable), even
if it's a pretty ugly organizational construct. Were you pointing
out that I was missing tests for something like it or did you want
to disallow it? If the former, I'll add tests for it.
> > Note that vars/vars_dbus_9.sd veers into stress test land, as the
> > combinatoric expansion results in over 1000 dbus rule entries being
> > generated, which means that DFA reduction on all the fields takes
> > noticeable amounts of time (around 1s on my i5 ivy-core laptop).
> >
> heh I'm good with that, I do think it might be good to add some variable
> expansion tests to the stress tests, something that will take a minute
> or two to reduce.
The stress tests in their current form do do variable expansion,
though in their current form I don't think they're the most significant
source of work for the parser. (To give you some idea, it currently
takes 15-18 minutes to run the parser over 1000 profiles generated
by the stress generator.)
The stress tests do need to be improved to incorporate a bunch of the
newer language features that we've incorporated.
--
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130909/ae3da98d/attachment.pgp>
More information about the AppArmor
mailing list