ubuntu-phone team mailing list archive

[Robert Ancell <robert.ancell@xxxxxxxxxxxxx>]

On Fri, Mar 7, 2014 at 6:19 AM, Sebastien Bacher <seb128@xxxxxxxxxx> wrote:

> 1. using accountsservice there as well, maybe adding support for "volatile"
> informations which wouldn't get store.
>
> That's the first suggestion made and some people started work using that
> approach. It feels suboptimal though, since it involves making 2 running
> processes talk by using a third process as proxy (which was not designed for
> that usecase).

I don't think there's an issue using a proxy process here. None of the
information (that I know of) has particularly high timing requirements
and for large sized data (e.g. photos) we have another solution (see
point 3). It's nice to have a third process involved as the greeter
may not be the only thing that needs this information, e.g. perhaps
something in-session would also like to show information about other
users.

When I last talked to the accounts service developers they didn't
really have a use case it was designed for. They essentially explained
to me they needed a D-Bus service to provide user information and this
is what they ended up with. They weren't sure if it would remain
forever or it might be replaced by sssd.

The issues I see with accounts service as it is:
- It's designed to show information per user, and we want to show per
session information. I don't see this as a major problem as we enforce
one (graphical) session per user in the display manager. The greeter
knows if you are logged in so can ignore any information that is not
appropriate when a session is not running.
- We have ever increasing amounts of information we want to provide to
the greeter. Ryan made the accounts service extensible so this is no
longer a problem.
- The information provided is supposed to be public and we may add
information that should not be publically visible. We can work around
this by only allowing the lightdm user to read some information using
PolicyKit if needed.

> 2. get lightdm to connect to the user-session bus and send back selected
> informations to the greeter.
>
> That seems like the most flexible/powerful solution, giving access to the
> user session might be a concern for security though.

Replied previously in Thomas' email but essentially LightDM doesn't
know there is a session bus and has no way to connect to it.

> 3. having a subdirectory in the user's XDG_RUNTIME_DIR, which is visible to
> the greter via a privileged protocol in lightdm (lightdm opening files and
> sending content, or using fds are possible options)
>
> that should do the job, be easy enough and not risk exposing too much from
> the user session

We have a shared data system thanks to Michael Terry's work [1]. This
allows a secure method of greeters and sessions creating files that
are accessible to both. What this doesn't cover is a method of
signalling. I raised this in the merge proposal, but we didn't come up
with a good solution. In the current solution LightDM doesn't care
what is in the directories, it is up to the sessions and greeters to
set this up (this seems somewhat a recipe for future failure).


So, to come back to the original issue - I think accounts service is a
suitable solution for status information being passed from the session
to the greeter and we should continue to use it. There's some other
issues not raised about transferring large amounts of data (see point
3) and signalling more than just status (e.g. new photo, control media
player) which are not fully resolved.

--Robert

[1] https://code.launchpad.net/~mterry/lightdm/shared-data-manager/+merge/207058