touch-packages team mailing list archive

[Alberto Mardegan <1478514@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

In the last few months we've been working on a simplified API for online accounts, targeted at confined applications. The whole API is provided by a D-Bus service (com.ubuntu.OnlineAccounts.Manager, and the interface has the same name) and doesn't require any of the other rules currently defined in the "accounts" policy.
This new API is also more limited than the current one: it doesn't allow modifying the accounts or enumerating the applications registered with OA.

We would like that developers of confined applications switch to the new
API. However, we cannot remove the old one, because it will still be
used by some system services; moreover, the current API with the
"accounts" policy will still have to be used by (even confined) account
plugins. So, the two APIs need to coexist.

The question is whether the apparmor policies should be distinct, or
whether the new rule for the v2 API should be added to the existing
"accounts" policy.

My proposal would be to create a new policy for the v2 API, and call it "accounts_read". The existing "accounts" policy should remain unchanged, but it would be great if the click-reviewer-tool could be modify to restrict its usage for account_plugins only. If the "accounts" policy is used by a confined click app, that should trigger a manual review.
These checks should be activated only if the framework being used is ubuntu-sdk-15.10 or later, in order not to cause disruptions to applications which are currently working fine.

I don't know if it's possible for the click-reviewer-tool to do these
checks, and in any case all the above is just my idea; different
suggestions on how to handle the transition are very welcome.

** Affects: apparmor-easyprof-ubuntu (Ubuntu)
     Importance: Undecided
         Status: New

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

Title:
  Support Online Accounts v2 API

Status in apparmor-easyprof-ubuntu package in Ubuntu:
  New

Bug description:
  In the last few months we've been working on a simplified API for online accounts, targeted at confined applications. The whole API is provided by a D-Bus service (com.ubuntu.OnlineAccounts.Manager, and the interface has the same name) and doesn't require any of the other rules currently defined in the "accounts" policy.
  This new API is also more limited than the current one: it doesn't allow modifying the accounts or enumerating the applications registered with OA.

  We would like that developers of confined applications switch to the
  new API. However, we cannot remove the old one, because it will still
  be used by some system services; moreover, the current API with the
  "accounts" policy will still have to be used by (even confined)
  account plugins. So, the two APIs need to coexist.

  The question is whether the apparmor policies should be distinct, or
  whether the new rule for the v2 API should be added to the existing
  "accounts" policy.

  My proposal would be to create a new policy for the v2 API, and call it "accounts_read". The existing "accounts" policy should remain unchanged, but it would be great if the click-reviewer-tool could be modify to restrict its usage for account_plugins only. If the "accounts" policy is used by a confined click app, that should trigger a manual review.
  These checks should be activated only if the framework being used is ubuntu-sdk-15.10 or later, in order not to cause disruptions to applications which are currently working fine.

  I don't know if it's possible for the click-reviewer-tool to do these
  checks, and in any case all the above is just my idea; different
  suggestions on how to handle the transition are very welcome.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+bug/1478514/+subscriptions