ubuntu-phone team mailing list archive

[James Henstridge <james.henstridge@xxxxxxxxxxxxx>]

On Thu, Oct 2, 2014 at 7:14 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> On 10/02/2014 01:22 PM, James Henstridge wrote:
>> I don't know the exact details of the scope Chris ran into this with,
>> but I am curious about how this ACL is being checked.  I do know that
>> Chris's scopes are Click packaged, so they will be running with an
>> AppArmor profile name of the form "$packagename_$scopename_$version",
>> even if that profile is equivalent to "unconfined".  Is that going to
>> pass this ACL check?
>
> Mmm... this is interesting. So, regardless of the contents of the
> profile, OA will see the app as "$packagename_$scopename_$version", and
> it will let it access the desired account only if
> "$packagename_$scopename_*" is present in the account's ACL.

So how does an app/scope/whatever get itself added to this ACL?
Should signond be doing a trust store check when a process with an
unknown AppArmor label tries to access an account's secrets so the
user can decide?


>> I'd imagine the same issue is going to affect any application that
>> uses Click packaging too.
>
> If you mean to say that any application that uses Click packaging can't
> just access any account it wishes, that's indeed true.

Well, as more and more of the apps and scopes in the image are
converted to Click packaging, this default exception for the
"unconfined" label is going to become less useful.  It's also worth
noting that the AppArmor label for click apps and scopes is going to
change each time a new version is released, so there needs to be some
way to add to the ACL for an existing account or account service.

> We have an API to
> request access to an account (and I realize just now that's not listed
> in developer.ubuntu.com), and that's via the "Setup" element of the
> "Ubuntu.OnlineAccounts.Client 0.1" QML module.
> The UI flow is described here:
> https://wiki.ubuntu.com/OnlineAccounts#App_access
>
> Scopes need to call this method as well, if they want to access the
> account. IIRC, the plan was to have a scope-config tool which would do
> that on their behalf.
> (the other option is to go to the Accounts panel in the system settings,
> click on the desired account and enable the application/scope from there)

Scopes are not using the QML binding for Online Accounts (they are not
GUI apps after all).  Could you explain what changes are needed for
apps using libaccounts-glib/libsignon-glib to work with this system?

Thanks,

James Henstridge.