ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #10052
Re: Addition of signon-apparmor-extension
On Fri, Oct 3, 2014 at 4:15 AM, Alberto Mardegan <
alberto.mardegan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References