Doesn't apply --include to newly installed clicks

Why not just change the ordering and install the click before running "phablet-config $ADBOPTS autopilot --dbus-probe enable"? We could adjust click-apparmor to remember the result, but I specifically went this route because --include-path is not supposed to be used under normal circumstances and I would hate to make it too easy to have the changes be persistent since it opens a security hole.

We shouldn't need to rebuild the click hooks if nothing has changed right? I push tests over and over manually without re-running the command.

Nicholas-- you don't *if* all the clicks that you want to test are already installed when you run aa-clickhook --include.... Martin was wanting to change that ordering requirement.

@Jamie, I was trying to ask if I needed to run it again if the policy hans't changed. Imagine this,

I install a new music app, then run aa-clickhook . . .

Next, I install yet another music-app with the same policy. I also install a new version of clock, again with the same policy as the previously installed version.

Do I need to run aa-clickhook again after installing any of these apps?

@Nicholas, if the version of the click hasn't changed, then you shouldn't have to run it again. If it has, aa-clickhook will be run as part of the click install and so you would have to run aa-clickhook --include-path=... again.

Jamie,

as I said on IRC I might misunderstand what that aa-clickhook command actually does. But as it takes very long (~ 1 minute), I'd rather just use it once ever instead of calling that for every click package that we test. That's why I'd like to have a semantics where you call it once after configuring the phone for testing, and from then on the existing click hook just does what it needs to do (i. e. apply the hook to newly installed clicks), or I have to call aa-clickhook manually with the --include but without -f (less discoverable, but should still be fast).

If by design neither of this is possible, then of course I can turn it around and always rebuild the whole thing after installing any click. That'll slow down testing but otherwise is of course entirely possible.

Thanks!

The aa-clickhook command works within the click system hook system and as such will generate profiles apparmor for any click packages that have a security manifest defined but do not have an apparmor profile generated for the manifest. It will regenerate apparmor profiles if the mtime on the symlink to the security manifest in /var/lib/apparmor/clicks is newer than the mtime of the apparmor profile. aa-clickhook -f unconditionally regenerates all the profiles.

In thinking about this, you can leverage this behavior like so:
1. phablet-config $ADBOPTS autopilot --dbus-probe enable
2. install list of clicks
3. touch -h /var/lib/apparmor/clicks/<list of profiles>.json
4. aa-clickhook --include=/usr/share/autopilot-touch/apparmor/click.rules

I verified this works as intended-- only those clicks whose security manifest was touched get the profile regenerated. I will update the man page for aa-clickhook for all of this.

Many thanks Jamie! I implemented this now in http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=commitdiff;h=b33d5a6e . While that workaround is now 3.84 times more ugly than before ☺ it reduces the time for doing this from ~ 1 minute to ~ 1 second, which is great.

Since I'm uncomfortable making the originally requested change to click-apparmor at this time, I am going to mark this as Won't Fix for now. If needed, we can re-review this or other workarounds in the future-- at which point, feel free to put the bug back at New.