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
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
