[apparmor] [patch] introduce AppArmorBug exceptions
Steve Beattie
steve at nxnw.org
Fri Nov 14 17:42:08 UTC 2014
On Thu, Nov 13, 2014 at 06:59:30PM +0100, Christian Boltz wrote:
> I'd prefer the name AppArmorBug because it makes clear something is
> really broken. AppArmorAssert sounds too harmless ;-)
Heh, as opposed to "Oh, it's just a bug." :-)
> For the distinction, let me give you an example:
>
> a) AppArmorException: aa-logprof parses the profiles and finds a line
> that doesn't match any of the RE_* patterns. That's probably a syntax
> error in the profile - something that can happen after manually
> editing a profile.
>
> b) AppArmorBug: parse_audit_allow() finds out that matches.group('allow')
> contains "maybe" (hint: the regex explicitely checks for "allow|deny",
> so someone must have handed over a match object from a wrong regex -
> that's clearly a bug.
Right. That kind of stuff is typically what people use asserts
to catch. I don't really care what the name is, so long as we all
understand what it means.
> > That said, for broken policy type stuff, it'd be nice to suggest to
> > the user what's gone wrong and suggestions on how to fix it (yes, the
> > parser needs a lot of work on that, too; alas, lex and yacc are not
> > the friendliest for accomplishing such things.
>
> My TODO list is already long enough ;-)
So say we all.
> > As for your short-term implmentation:
>
> > All the behavior here is a duplicate of the AppArmorException. So it
> > would probably be better to inherit from it and override the behaviors
> > you want to change; e.g. for the time being:
> >
> > class
> > AppArmorExceptionClassToBeNamedLaterAfterManyLongTediousArgumentsOnIR
> > C(AppArmorException):
> > '''This class represents AppArmor exceptions "that should never happen"'''
> > pass
>
> KMail thinks your class name is too long ;-)
KMail's not the only one. :)
> Actually the goal is to use cgitb for all exceptions except
> AppArmorException (which should just print the summary, but not a
> backtrace) - but that's another patch (IIRC Kshitij has a draft for that
> already).
>
> This also means that AppArmorBug should be based on "Exception" so that
> it doesn't inherit the (planned) changed behaviour of AppArmorException.
> However I don't see a problem with making AppArmorBug behaving like a
> normal Exception, so the updated patch is:
Sure. Once we have more complex implementations of these, we can
re-examine whether a class hierarchy for them makes sense.
Acked-by: Steve Beattie <steve at nxnw.org>
Thanks.
> === modified file 'utils/apparmor/common.py'
> --- utils/apparmor/common.py 2014-10-14 10:54:39 +0000
> +++ utils/apparmor/common.py 2014-11-13 17:38:31 +0000
> @@ -35,6 +35,10 @@
> def __str__(self):
> return repr(self.value)
>
> +class AppArmorBug(Exception):
> + '''This class represents AppArmor exceptions "that should never happen"'''
> + pass
> +
> #
> # Utility functions
> #
--
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: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20141114/a8d6774c/attachment.pgp>
More information about the AppArmor
mailing list