ubuntu-phone team mailing list archive

[James Henstridge <james.henstridge@xxxxxxxxxxxxx>]

On Thu, Oct 2, 2014 at 5:52 PM, Alberto Mardegan
<alberto.mardegan@xxxxxxxxxxxxx> wrote:
> Hi,
>
> On 10/02/2014 05:12 AM, Chris Wayne wrote:
>> It seems that recently a package (signon-apparmor-extension) has been
>> included that has been causing some issues
>> (see https://bugs.launchpad.net/savilerow/+bug/1376445).
>
> I added a comment on the bug suggesting a fix.
>
>> Is there some apparmor policy group that I would need to include to be
>> able to access Online Accounts?  We have some scopes using accounts, and
>> they're failing to get tokens with the following error:
>>  GDBus.Error:com.google.code.AccountsSSO.SingleSignOn.Error.PermissionDenied:
>> Client has insuficient permissions to access the
>> service.Method:getAuthSessionObjectPath
>
> Unconfined applications can always access OA (so no, if your app is
> unconfined, apparmor doesn't block any access to OA), but then OA has
> its own ACL checks, and will allow only authorised processes to access
> the accounts.
> By default, all our plugins add "unconfined" to the account's ACL as
> soon as the account is created, in order to allow all unconfined
> processes to use the account. But the UbuntuOne plugin was not doing that.
>
> Can you please confirm that this problem only affects apps and scopes
> using the U1 account? Or does it affect other processes too?

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?

I'd imagine the same issue is going to affect any application that
uses Click packaging too.


James.