On 10/03/2014 07:41 AM, Chris Wayne wrote: > > > On Fri, Oct 3, 2014 at 4:15 AM, Alberto Mardegan > <alberto.marde...@canonical.com > <mailto: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 >
A click package need only specify the 'accounts' policy group and use policy_version 1.2 in the security manifest. This is true for both apps and scopes. (Prior to apparmor-easyprof-ubuntu 1.2.21, the accounts policy group was 'reserved', however, online accounts now has Mir trusted session support so it was moved to 'common' status. Also, recent versions of the click-reviewers tools know that accounts is ok to use by both apps and scopes). -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- 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
