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

Tue Aug 4 16:54:48 UTC 2015

On Sun, Aug 02, 2015 at 05:08:27PM +0200, Christian Boltz wrote:
> 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.

Yep, I agree, this particular fix is a short term thing.

In the long term, there's a couple of conflicting tensions here:
supporting a large enough set of features for apparmor to still
function/enforce usefully in a minimal environment as well as a richer
set of helpful functionality at the expense of a larger install.

I know John would like to rewrite aa-status as a compiled C/C++/what-
have-you binary that does not require an interpreted environment
available. However, unless libapparmor grows a significant set of
functionality, I don't think addressing all the bugs above will be
easily possible in such an environment. However, I *do* think we could
have a separate aa-is-enabled compiled tool that answers the question
dh_apparmor needs to know, and let aa-status make use of the python
apparmor module to support the more detailed sorts of reporting that
users/admins want to see and address the open issues you highlighted.

> > 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.

No, apparmor-utils does depend on python3-apparmor (and in my
2.10 upload that just landed 15.10/wily, those two are now version
tied). The issue is that aa-status is shipped in the base apparmor
package, which does not depend on 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

I've forgotten what I meant to say in the footnote, perhaps something
about even supporting minimal environments that don't wish to have
python installed at all (I know there are groups pushing in that
direction). I think having a C-ish aa-is-enabled utility would help
with that.

> > 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? ;-)

Yep, thanks.

-- 
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/20150804/8ebfe4bc/attachment.pgp>