ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Fri, Mar 7, 2014 at 12:38 AM, Robert Ancell
<robert.ancell@xxxxxxxxxxxxx> wrote:
> 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.
>

+1, who would be the best person to look into the two open points that
Robert has raised here?

Thomas

> --Robert
>
> [1] https://code.launchpad.net/~mterry/lightdm/shared-data-manager/+merge/207058
>
> --
> 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