AIUI this is not a bug in click-apparmor but click itself. While the
hook is being run, click isn't updating the timestamps on the click hook
symlink. Ie:

Install the old click:
$ cd old
$ sudo click install --force-missing-framework --user=$USER ./*0.7_all.click 
--allow-unauthenticated
...
$ stat /var/lib/apparmor/clicks/*_0.7.json 
...
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-03-08 16:31:16.352376489 -0600
Modify: 2016-03-08 16:31:16.288376439 -0600
Change: 2016-03-08 16:31:16.288376439 -0600
...
$ cat /var/lib/apparmor/clicks/*_0.7.json
{
  "template": "ubuntu-webapp",
  "policy_groups": [
    "audio",
    "location",
    "networking",
    "video"
  ],
  "policy_version": 1.0
}


Install a click with an updated security manifest but same version:
$ cd ../new
$ sudo click install --force-missing-framework --user=$USER ./*0.7_all.click 
--allow-unauthenticated
...
$ stat /var/lib/apparmor/clicks/*_0.7.json 
...
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-03-08 16:31:16.352376489 -0600
Modify: 2016-03-08 16:31:16.288376439 -0600
Change: 2016-03-08 16:31:16.288376439 -0600
...

$ cat /var/lib/apparmor/clicks/*_0.7.json
{
  "template": "ubuntu-webapp",
  "policy_groups": [
    "audio",
    "location",
    "networking",
    "video",
    "camera"
  ],
  "policy_version": 1.0
}

Notice that will the contents of the security manifest is updated, the mtime of 
the symlink was not. click-apparmor currently requires that the mtime be 
updated. This is due to install_link() in lib/click/hooks.vala:
    if (is_symlink (link) && FileUtils.read_link (link) == target)
            return;

One way to achieve this would be to recreate the symlink on install if
the symlink exists. Alternatively, click-apparmor could also consider
the ctime of the target file compared to the symlink's mtime. While it
seems like a fix in click is the right choice, I believe only click-
apparmor cares about these sorts of things, and a change there would be
localized to only click-apparmor and therefore less risky.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click-apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1549369

Title:
  Updating the apparmor manifest and deploying the new code without
  increasing app version does not trigger apparmor profile update on the
  device.

Status in Client Developer Experience:
  New
Status in Canonical System Image:
  Confirmed
Status in click-apparmor package in Ubuntu:
  Confirmed

Bug description:
  On Krillin, as of rc-proposed r264,

  modifying the application apparmor manifest and then deploying the
  application to the device *without* increasing the app version will
  not trigger the apparmor profile update.

  As a consequence, the developer is left confused because the app is
  still complaining about apparmor denials even after he modified the
  apparmo manifest and deployed the new .click package.

  Deploying changes to an application without updating its version
  number is a quite common practice, especially while in development
  phase.

  That is why I believe we should fix this bug as soon as possible, to
  make life of developers easier.

  Reference of a similar bug, which was however more Snappy specific:
  https://bugs.launchpad.net/ubuntu/+source/click-apparmor/+bug/1422744

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-developer-experience/+bug/1549369/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to