[apparmor] aa-enabled

[John Johansen]

On 11/22/2015 07:20 AM, Christian Boltz wrote:
> Hello,
> 
> aa-status --enabled (and only --enabled AFAIK) is used in dh_apparmor, 
> which means we have to keep the dependencies as small as possible, 
> especially "import apparmor.$something".
> 
> Needless to say that this makes improving  aa-status quite difficult.
> 
> We discussed splitting off an "aa-enabled" tool that just does what 
> aa-status --enabled does with minimal dependencies.
> 
yes

> To allow a smooth transition, I propose to add a little aa-enabled tool 
> to 2.9 and 2.10 which just does
> 
>     #!/bin/sh
>     exec aa-status --enabled
> 
hrmmm, this certainly doesn't solve the problem, and hardly seems worth
doing as a backport. If we were to pull anything back to 2.9 or 2.10
I think I would rather the bash script or ideally a simple C program
so there are no interpreter dependencies to worry about.

> This means Debian and Ubuntu can switch dh_apparmor etc. to use 
> aa-enabled instead of aa-status --enabled _now_ (assuming it fits for 
> them) instead of having to wait for a major AppArmor release. This 
> allows a longer migration period.
> 
sure they could switch now, but such a change isn't going to show up
in the current releases. It will only be dropped into new ones

> For trunk, I propose aa-enabled should actually do the work itsself - 
> see the "Re: [apparmor] [patch] utils: make aa-status(8) function 
> without python3-apparmor" mail for a proposal.
> 
I agree it should do it itself, and I counter with the following C
program

---

#include <errno.h>
#include <stdio.h>
#include <sys/apparmor.h>

int main(int argc, char **argv)
{
	if (aa_is_enabled()) {
		printf("Y");
		return 0;
	}
	printf("N");
	return errno;
}