[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