[Apparmor-general] apparmor-parser gone wild?!

[Christian Boltz]

Hello,

Am Freitag, 5. September 2008 schrieb John Johansen:
> Christian Boltz wrote:
> > Am Freitag, 5. September 2008 schrieb John Johansen:
> >> Christian Boltz wrote:
> >>> As you can see, apparmor_parser takes 100% of the cpu and 14.4%
> >>> of the available memory (the server has 6 GB RAM!).
> >>
> >> uhm, yeah this is a little ugly, there is a "bug" in the dfa
> >> generation that causes some policies to consume unbelievable
> >> amounts of ram and cpu.  It is a problem that I am actively
> >> working on now.
> >
> > Bug number?
>
> 421077 its an L3 bug against SP2, but its the same problem and exists
> in 10.3, 11.0, and 11.1 alphas.

I get "access denied" - can you CC me please?
(I'm suse-beta (at) cboltz.de in bugzilla)

BTW: I'm also affected by bug 408846 and bug 408877 - anything else that 
I should know about apparmor on 11.0? ;-)

> The patch for the mem leak, has also been done for the 11.0 parser,
> which reduce the memory used when there are hats but not the cpu.

> > (what command line is used at the end of logprof?)
>
> log prof does
>
> /bin/cat '$filename' | $parser -I$profiledir -r >/dev/null 2>&1"

Hmm, is it really a good idea to /dev/null stderr?

> though you could just as easily do
>   apparmor_parser -r <profile name>
>
> perhaps a more useful test however is
>   apparmor_parser -S <profile_name> >tmpfile

This creates a 5.9 MB file for the apache profile, but didn't take an 
insane time (10s for all my profiles - >90% of this time (and about 850 
MB of RAM) is used for the apache profile).

However, I was unable to reproduce the endless hang with this command.
(But I also didn't manage to cause a hang using aa-logprof today.)

> My guess is the unkillable bug, is to do with loading and replacement
> of policy, which would look like the apparmor_parser process but
> would be in the kernel and thus unkillable.

Yes, probably.

> > If needed, I can provide SSH access to the server and a root screen
> > session to attach to. Just send me your SSH key in a signed mail
> > and offer some possible timeframes (late evening in german time is
> > probably the best).
>
> we just might do that, but not just yet as I am unsure of what my
> internet access will be over the next couple of days.  It is entirely
> possible I won't have any access until monday.

Just tell me when you have time and internet access ;-)

> >> yes, please send them to me and I will do some testing against
> >> your policy.  This should also enable me to make some
> >> recommendation about what you can do until I get this nasty bug
> >> fixed.
> >
> > I'm quite sure the answer will be something like "simplify your
> > apache profile" because this is the largest profile and has lots of
> > hats.
>
> Actually no, I am more of the opinion that the tools need fixed or
> improved if policy size is a problem.  

Of course - I was thinking about the profile simplification as a 
temporary solution only.

> I am trying to address the memory/computation problems in two ways.
> First by improving the code that computes the dfa, and secondly by
> allowing for compiled policy caching, so policy that hasn't changed
> doesn't need to be recompiled.

Whenever you have test packages of the parser fix available, give me the 
download address ;-)

(and thanks for the additional information not quoted here!)


Regards,

Christian Boltz
-- 
"Wouldn't the sentence 'I want to put a hyphen between the words Fish
and And and And and Chips in my Fish-And-Chips sign' have been clearer
if quotation marks had been placed before Fish, and between Fish and
and, and and and And, and And and and, and and and And, and And and
and, and and and Chips, as well as after Chips?"   -- BSD fortune file