hi, On Thu, Mar 6, 2014, at 12:19, Sebastien Bacher wrote: > 1. using accountsservice there as well, maybe adding support for > "volatile" informations which wouldn't get store.
I don't like this. The reason that we ever started to put information in accountsservice was pretty simple: because we needed access to certain information when the user is not logged in and therefore we don't have access to their home directory (possibly due to encryption or NFS). This was never meant as a bridge between the session and the greeter. This was always explicitly because we needed a place for data when the user is _not_ logged in. This is also quite a bad approach for dynamic information because such information could become stale when the user logs out (unless we add hooks to logind to tell accountsservice when to flush this information). From a slightly less practical and more theoretical side it also "feels wrong" to be storing information such as MPRIS media player stuff inside of anything that has any kind of state at all (volatile or otherwise) because we would need something in the session to monitor the state and push it into the service, and this information could very easily get stale if something stopped working properly. Storing the information in accountsservice also has the highest overhead of all of the mentioned approaches, even if we mark the data as volatile and avoid saving it to disk. First we need a component in the session to do the monitoring of whatever state we want to update in the greeter. Then we have to have this component send a message to a process on the system D-Bus and this process has to do polkit checks (more D-Bus messages) in order to ensure that the sender has the right to make the request. It then has to update its internal state and fire a signal across the system D-Bus information others that the change has taken place. > 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. In a sense, this is the "best approach". I think having lightdm come onto the user's session bus as soon as the user has logged in has a lot of appeal for quite some reasons. If we are having lightdm handle the locking then this could allow lightdm to communicate with the session (and its contents) about things like inhibit, for example. This would also be the best approach to allowing us to model dynamic information (such as the state of MPRIS music players). It would not be subject to stale data about the playing song, for example, because the information would not be persistently stored anywhere at all -- only proxied. It would be lightdm actively monitoring things, rather than a utility component in the user's session (which all other approaches would require). The drawback here is security of course. Attaching a privileged component to the user's session bus exposes a lot of surface area to possible attack. Even with system level D-Bus components running as root we don't see this level of exposure because they are hidden behind the D-Bus daemon, which provides an additional level of protection. In this case, the user controls the D-Bus daemon, so they can inject whatever junk they want directly into this component. If we feel that we can manage the security implications of this (like, having it not run as root, for example) then I think this is the best approach. I think it might be difficult to convince ourselves of this, however. > 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 This is a balanced approach. It removes the ills of abusing accountsservice for something that it has no logical business doing and it provides protection against staleness because of how strictly logind manages the directory (blowing it away at logout, guaranteed fresh at new login, etc.). In common with the accountssevice approach, it would still require an extra component in the session, but this component would be a lot easier to write and would have far lower overhead (since it only writes files to a tmpfs -- almost free). On the lightdm side, the interface could be very simple (and therefore quite safe). Lightdm would grow an API on the greeter socket protocol that would look like one of two things: 1) API to read a file from a restricted subdirectory of a user's XDG runtime dir, plus a change notification API (probably based on inotify directly). This is the bigger of the two possible APIs, but more traditional and sane. 2) API to have an open file handle to the directory sent to the greeter directly. The greeter could then inotify() on this file handle for itself and also openat() files contained within it. Escaping via ".." would not work because the runtime directory is guaranteed to have permissions 0700. This is a very small API but it has a weird flavour. I think it's quite fine, though. In either case, the idea of placing a socket in this directory may also be interesting. In both cases, we would need a separate call to support this. The reason for that in case 2 is because there is no *at() equivalent for the connect() system call as used on AF_UNIX. Some other possibilities are worth mentioning: Michael Terry tells of a directory that is already shared between the user and the lightdm greeter. This is used for storing bulk data not appropriate for the accountsservice (such as the user's face photo). In fact, in light of this, one wonders why we have the accountsservice storing any information at all -- it could all go here. I do not consider this an appropriate place for the transient state that we're talking about here though, for the above-mentioned concerns about staleness. A final possibility is that we find a simple way to create a socket that can be shared between the session and the greeter and write a small program to shuffle data across it. This shares the problem that we need a component in the session (as with all of the cases above except the one where lightdm gets directly on the session bus). We also have to figure out a way to share the socket, but this doesn't seem like it's a particularly difficult problem to solve. Cheers -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
