On Fri, Mar 7, 2014 at 6:19 AM, Sebastien Bacher <seb...@ubuntu.com> 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 -- 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