[apparmor] [patch] utils: make aa-status(8) function without python3-apparmor
apparmor at cboltz.de
Sun Aug 2 15:08:27 UTC 2015
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
display profile attachment
handle profile name/attachment
handle profile name with globbing
listing disabled profiles and processes that would be covered by
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 , so perhaps it does
> 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? ;-)
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]
More information about the AppArmor