ubuntu-phone team mailing list archive

[Ryan Lortie <desrt@xxxxxxxx>]

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