ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #10051
Re: Addition of signon-apparmor-extension
-
To:
Ubuntu Touch <ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
-
From:
Alberto Mardegan <alberto.mardegan@xxxxxxxxxxxxx>
-
Date:
Fri, 03 Oct 2014 11:15:15 +0300
-
In-reply-to:
<CALcaVOnoBnvpZCUPA0-_tz2fw8AztUNF7WHqCqsR=9jf3U5o5Q@mail.gmail.com>
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
On 10/03/2014 09:53 AM, James Henstridge wrote:
> 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?
Not exactly: the way that it's designed to work is that if the ACL check
fails, the access is just denied, without any user prompting. User
prompting happens before an application starts using an account, and
there's an API for that, which -- if the user granted access -- will
cause the app to be added to the ACL.
More on this below.
>> 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.
Note that while we add the full AppArmor label into the ACL, we compare
just the first two components; so, different versions of the same app
(or scope) will retain the permissions given to an older version.
>> 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?
Well, strictly speaking, the QML API we are exposing is also not GUI (it
doesn't depend on QtQuick or QtGui), but anyway we are also exposing a
Qt API for that. You can see it in use here:
http://bazaar.launchpad.net/~unity-team/unity-scopes-shell/trunk/view/head:/src/Unity/scope.cpp#L1259
If your scopes are written in Go, I would strongly recommend you to wrap
the Qt library (it's basically just one method call); alternatively, you
could even use a raw D-Bus call (it's just one method), but that should
be considered only as a temporary hack, because we don't guarantee any
stability of the D-Bus API.
Ciao,
Alberto
Follow ups
References