[pkg-apparmor] Bug#880859: apparmor-notify: packaging patches first utils/notify.conf but then overwrites it with debian/notify/notify.conf

[intrigeri]

Hi Salvatore!

Salvatore Bonaccorso:
> While looking at apparmor-notify I noticed that in the source package
> we first patch utils/notify.conf to set use_group="adm" (from the
> original "admin"). This was actually handled a couple of yerars back
> in #660078). But then we install a custom debian/notify/notify.conf
> setting the group to "sudo".

Good catch!

> Which approach is more sensible for Debian's version?

> Or, but not checked the code if 

>> or -even better IMHO- it may not set use_group at all, given
>>  aa-notify only uses this setting if it is set.

> is still true, then just drop setting of use_group?

I took a good look at it and I don't understand what value use_group
is supposed to bring to the user/admin.

I suspect the original rationale behind use_group was to:

1. avoid uselessly running an aa-notify process in a desktop session
   for a user who is not allowed to read the logs anyway.
2. log a helpful message on aa-notify startup if the user is not
   allowed to read the logs.

So in theory it's worth setting use_group on Debian to the group that
can read these logs by default, that is "adm" on current testing/sid.
But aa-notify checks that it can read the selected log file before it
checks membership wrt. use_group, and aborts if the log file is not
readable, so in practice both of these reasons are moot and I fail to
understand what use_group is supposed to be useful for.

⇒ I'll unset use_group in the next upload of the package to Debian.

Then, if someone explains what use_group is supposed to be useful for,
we can reconsider later :)

Cheers,
-- 
intrigeri