[apparmor] aa-enabled

[John Johansen]

On 11/24/2015 03:03 PM, Christian Boltz wrote:
> Hello,
> 
> Am Dienstag, 24. November 2015 schrieb John Johansen:
>> On 11/22/2015 07:20 AM, Christian Boltz wrote:
>>> 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
> 
> Depends how you define the problem ;-)
> 
> IMHO it is "calling aa-status --enabled" (especially when done from 
> dh_apparmor and similar packaging helpers), and that can be solved by 
> such a wrapper. (Getting dh_apparmor changed might be harder than 
> getting a new AppArmor version in.) 
> However...
> 
>> 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.
> 
> ... I won't object if we backport the "real" aa-enabled ;-)
> 
>>> 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
> 
> Of course it will only be changed for new releases, but I'd guess 
> getting a minor release in is easier shortly before a distribution  
> release.
> 
>>> 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;
>> }
> 
> Nice trick - you are using libapparmor to hide most of the code ;-)
> (that's not really bad because it avoids code duplication, but makes the 
> comparison a bit unfair ;-)
> 
> Oh, and the C code has a bug - like aa-status --enabled, aa-enabled 
> should only set the exitcode, but not print anything.
> 
> Anyway, I can live with both solutions as long as we get aa-enabled 
> added ;-)
> 
hrmmm, I think I'd rather leaving human readable output as the default
and having a quiet flag for just the error code.

since we are replacing
  aa-status --enabled
I don't see how
  aa-enabled --quiet
is any worse, and then a user can also easily use the tool