[apparmor] [patch] utils: make aa-status(8) function without python3-apparmor

[Christian Boltz]

Hello,

Am Freitag, 31. Juli 2015 schrieb Steve Beattie:
> In the 2.10 cycle, Christian added improved exception handling support
> to the python tools, to improve the output and assist in diagnosing
> problems. To do so, this meant importing a module from the apparmor
> python module (python3-apparmor). For most of the python utilities,
> other portions of the apparmor python module are already imported, so
> this wasn't a dependency change. However, the exception to that is
> aa-status(8), which intentionally did not depend it, so as to still
> be usable in minimal environments, where administrators wish to
> install as little extraneous as possible.

I understand the goal, but I'm not sure if we should keep it that way on 
the long term - it leads to some duplicated code. For example, aa-status 
find_apparmorfs() is a cheap copy ;-) of aa.py check_for_apparmor() 
which basically does the same, but with less checks etc.

I'd prefer to accept the dependency in the interest of avoiding 
cuplicated code and using the same functions everywhere. This is 
especially true because some changes we need to do will need code from 
the apparmor.* modules.

For details, see
https://bugs.launchpad.net/apparmor/+bug/1453944
    display profile attachment
https://bugs.launchpad.net/apparmor/+bug/731175
    handle profile name/attachment
https://bugs.launchpad.net/apparmor/+bug/595714 
    handle profile name with globbing
https://bugs.launchpad.net/apparmor/+bug/1430513
    listing disabled profiles and processes that would be covered by 
    those profiles

Fixing and implementing these things without a dependency on apparmor.* 
would mean _lots of_ duplicated code.

That said - I can live with making the improved error handling optional 
as long as this is the only thing we import from the apparmor.* modules, 
BUT I will need apparmor.* imports to fix the issues mentioned above.

> In Ubuntu, aa-status is used as part of the generated dh_apparmor
> postinst snippet to determine whether apparmor is enabled, and if so,
> to go ahead and load the specified apparmor policy. When attempting
> to land apparmor 2.10 in Ubuntu, this caused this snippet to fail
> due to python3-apparmor not being installed by default. (Hooray for
> autopkgtests actually catching it!)

I'd argue that this sounds more like a missing dependency - 
apparmor-utils (should) require python3-apparmor.

> The following patch attempts to address this by having aa-status
> attempt to import the fancier exception handling code, but continue
> on if it fails and fall back to using regular python exceptions.
> 
> I'm of two minds about this patch. On the one hand, the issue is
> related directly to a quirk of how apparmor is packaged for
> debian/ubuntu, and thus not really appropriate for upstream apparmor.
> On the other hand, other distributions/users may also wish to have a
> similar set up for more minimal environments [1], so perhaps it does

EMISSINGFOOTNOTE

> make sense for upstream.

It doesn't hurt, therefore
Acked-by: Christian Boltz <apparmor at cboltz.de>
(did I already mention that fixing the issues listed above will need 
some apparmor.* imports? ;-)


Regards,

Christian Boltz
-- 
I peek out at the world through a 400Kbit pin-hole right here in
Germany, less than 100km from the source.  Bicycle+usb-stick is a
bigger pipe to NBG for DVD size downloads :)
[Mike Galbraith in opensuse-factory]