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

John Johansen john.johansen at canonical.com
Tue Nov 24 09:34:47 UTC 2015


On 11/22/2015 07:18 AM, Christian Boltz wrote:
> Hello,
> 
> any comments on this?
> 
It is interesting but I am not fond of it. It also should have another test

> Am Mittwoch, 5. August 2015 schrieb Christian Boltz:
>> Am Dienstag, 4. August 2015 schrieb Steve Beattie:
>>> However, I *do* think we could
>>> have a separate aa-is-enabled compiled tool that answers the
>>> question
>>> dh_apparmor needs to know,
>>
>> So dh_apparmor only needs/uses aa-status --enabled?
>>
>> The only thing I can say about that is:
>>
>>     Go away or I will replace you with a very small shell script!
>>
>> ;-)
>>
>>
>> #!/bin/bash
>> test -e /sys/module/apparmor || exit 1
if [ `cat /sys/module/apparmor/parameters/enabled` != 'Y' ] ; then exit 5 ; fi

>> mountpoint=
>> while read device mountpoint fstype trash ; do
>>     test "$fstype" == "securityfs" && break
>> done < /proc/mounts
>> test -n "$mountpoint" || exit 3
>> test -d "$mountpoint/apparmor" || exit 4
>> test -n "$(<$mountpoint/apparmor/profiles)" || exit 2
>> exit 0
>>
>> This script should work, however I gave it only a quick test and
>> didn't test on a system without AppArmor (but tested by modifying the
>> script to cause negative answers in various conditions).
>>
>> I know I'm using quite some bashisms here, but IMHO that's cheaper
>> than calling some external helpers (the first version of the script
>> had a grep with an interesting regex, and a cat for testing if
>> $mountpoint/apparmor/profiles isn't empty - well, "grep .." would also
>> work ;-)
>>
>> Oh, and the exitcodes don't always match aa-status exactly, but that
>> could be fixed by an additional test if needed.
> 
> 
> Regards,
> 
> Christian Boltz
> 




More information about the AppArmor mailing list