On Fri, Oct 3, 2014 at 4:15 AM, Alberto Mardegan < alberto.marde...@canonical.com> wrote:
> 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. > We can't do a D-Bus call from a click package scope anyway can we? I think dbus was explictly denied by AppArmor > > Ciao, > Alberto > > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
