On Fri, Mar 7, 2014 at 12:38 AM, Robert Ancell <[email protected]> wrote: > On Fri, Mar 7, 2014 at 6:19 AM, Sebastien Bacher <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
