[apparmor] aa-enabled
John Johansen
john.johansen at canonical.com
Wed Nov 25 10:18:08 UTC 2015
On 11/25/2015 01:41 AM, Christian Boltz wrote:
> Hello,
>
> Am Dienstag, 24. November 2015 schrieb John Johansen:
>> v3 containing all suggested changes + copyright and ifdef around
>> packaging defines for PACKAGE and LOCALEDIR, at least until make file
>> packaging can be worked out
>
> Looks good, I noticed just some minor details.
>
> Feel free to include easy to fix things in your commit, otherwise commit
> as acked by Seth and address this with a follow-up patch.
>
>> #ifndef PACKAGE
>> #define PACKAGE ""
>> #define LOCALEDIR ""
>> #endif
>
>> setlocale(LC_MESSAGES, "");
>> bindtextdomain(PACKAGE, LOCALEDIR);
>> textdomain(PACKAGE);
>
> I interpret this as not using translations for now, right? If that is
> easy to change, do it now - otherwise commit as is.
Nope, it is setup for translations, but there needs to be a little "packaging"
work that will define PACKAGE and LOCALDIR
The ifndef just lets me build and test without those defined
>
>> if (argc > 2) {
>> printf(_("unknown options\n"));
>
> This could also mean someone used
> aa-enabled --quiet --help
> which doesn't sound too useful, but will still result in a "wrong" error
> message.
>
> Adding a more detailed check just to print the "right" error message
> would be overmuch, so what about changing the error message to something
> like
> unknown or incompatible options
> ?
sure
>
>> case EACCES:
>> printf(_("Maybe - insufficient permissions to determine
>> availability.\n")); break;
>
> Do we need a "run aa-enabled as root" hint here?
>
uhm well it will depend on your version. Earlier versions of apparmor had the
DAC perms set incorrectly so you had to be root to check that it was enabled.
But you could also have apparmor (or another lsm) denying access to the
resources needed to determine if apparmor is enabled, so root is not necessarily
enough.
>> default:
>> printf(_("No\n"));
>
> How likely is it to hit this "no"?
> If "not very likely" - would it make sense to print out err to make it
> easier to find out what caused the "no"?
>
well this should only be enomem atm so yes we could, and probably print out
the error.
>
> Regards,
>
> Christian Boltz
>
More information about the AppArmor
mailing list