Dear Maintainer,

Please use the patch attached to add an apparmor profile for syndaemon
to your package.

At least for now, the profile is in "complain" mode, which means that
if syndaemon does something not defined in the profile, it will not be
impeded by apparmor -- only a message in the logs will appear. This
ensures that no permission issues will appear with the addition of
this profile.

Cheers,
--
Cameron Norman

On Sun, 7 Jun 2015 12:21:31 -0700 Cameron Norman  <camerontnorman@gmail.com> wrote:
 > Package: xserver-xorg-input-synaptics
 > Version: 1.8.2-1
 > Severity: wishlist
 > Tags: patch
 >
 > Dear Maintainer,
 >
 > Please use the patch attached to add an apparmor profile for
syndaemon
 > to your package.

I apologize -- I forgot to include the necessary Build-Depends on
dh-apparmor in that patch.

This new one should work correctly.

Cheers,
--
Cameron Norman

Hi,

<pkg-apparmor team member hat on>

the proposed confinement profile looks OK to me at first glance.
It's very simple so exceptionally I won't be requesting a review pass
on the AppArmor mailing-list :) And, given the profile is brand new,
flags=(complain) sounds reasonable as a first step.

Was this profile tested with syndaemon run by GNOME and/or by other
desktop environments?

Also, thanks a lot for using pkg-apparmor's usertags!

Cheers,
--
intrigeri

It was tested both running manually and with gnome-settings-daemon.

I looked at debian codesearch for packages that run syndaemon and it
yielded (in addition to g-s-d) mate-s-d, cinnamon-s-d, and xfce4-s-d.

The former two have the exact same code as g-s-d (they are g-s-d
forks) and the xfce4 code has similar options.

The main reason I included the flags=(complain) was because syndaemon
supports pidfiles in variable locations that I could not possibly
guess. No package in Debian makes use of the pidfile option, but users
may have custom xinitrc's and whatnot that do use it.

Cheers,
--
Cameron Norman

Cameron Norman wrote (08 Jun 2015 16:39:46 GMT) :

Great, thanks for the extensive research. Dropping the moreinfo tag,
then, and leaving it to maintainers to decide what to do with the
proposed patch.

This alone would not block me personally from shipping the profile in
enforce mode: in general, Debian's AppArmor profiles, much alike
Ubuntu's, try to make default things work out-of-the-box, but we can't
possibly guess and support all the niche use-cases one may have.
That's what local overrides are for :)

Cheers,