[apparmor] [patch] fix aa-logprof rewrite of PUx modes.

John Johansen john.johansen at canonical.com
Tue Apr 24 16:36:50 UTC 2012


On 04/24/2012 09:33 AM, Steve Beattie wrote:
> On Tue, Apr 24, 2012 at 04:09:26PM +0000, Seth Arnold wrote:
>> Modifying the emit routines rather than the datastructures seems
>> like the best approach -- it is afterall this particular format
>> that's broken.
> 
> The thing I don't like about this approach is that it treats the exec()
> modes independently when they're not. The other approach I considered
well currently they aren't as the backend only has a single bit for the safe
exec flag, but we can revisit that

> to solved it was to walk through the modes in a largish if-elsif...
> construct that was more explicit; i.e. in pseudocode:
> 
>   if (mode & AA_EXEC_PROFILE)
>     if (mode & $mode & AA_EXEC_UNCONFINED)
>       if (mode & AA_EXEC_UNSAFE)
>         emit "pux"
>       else
>         emit "PUx"
>     elsif (mode & $mode & AA_EXEC_INHERIT)
>       if (mode & AA_EXEC_UNSAFE)
>         emit "pix"
>       else
>         emit "Pix"
>     else
>       if (mode & AA_EXEC_UNSAFE)
>         emit "px"
>       else
>         emit "Px"
> 
>   elsif (mode & AA_EXEC_CHILD)
>     [blah blah, similar to above...]
> 
>   elsif (mode & AA_EXEC_INHERIT)
>     emit "ix"
> 
>   elsif (mode & AA_EXEC_UNCONFINED)
>     if (mode & AA_EXEC_UNSAFE)
>       emit "ux"
>     else
>       emit "Ux"
> 
> 
> but while I can see the value in being more explicit, I couldn't
> convince myself that there was a situation where the "correct"
> re-ordering of the existing code would still produce an incorrect mode,
> and the explicit approach results in an even longer function in a
> codebase that suffers from terribly long multiply if-nested functions.
> 
yeah its not worth it




More information about the AppArmor mailing list