[gdm-list] Making the greeter interface accessible from outside

[Giovanni Campagna <scampa giovanni gmail com>]

Hello gdm list,

as you may have heard from discussion on desktop-devel-list, one of
the features of the new screen lock is improved authentication, by
reusing the multi-stack gdm infrastructure. To do so, essentially we
need to talk to gdm-simple-slave, the way the GdmGreeter.GreeterClient
does now.

So, my question is, is there any particular reason why g-s-s uses a
private DBus server instead of the system bus?
If not, my plan is to make g-s-s grab
org.gnome.DisplayManager.<SeatId>.Slave on the bus and export
/org/gnome/DisplayManager/GreeterServer there. Then, because code
currently assumes there is only one greeter per slave, the following
changes would made:
- OpenConversation would check for permission and if successful return
a "conversation id" (an opaque generated token)
- all other methods would take this conversation id as the first
arguments - this accounts for both authentication and multiplexing of
clients
- signals TimedLoginRequested, DefaultLanguageNameChanged and
DefaultSessionNameChanged would be sent to all clients (or perhaps
moved to a different interface)
- other signals would be only sent to the owner of the relevant conversation
Internally, g-s-s would keep a hash table mapping conversation ids to
GdmSessionDirect and bus unique name.
Drawbacks of the proposal: passwords are sent in clear text on the
bus. Bus policy does not help, because if unprivileged processes are
allowed to start conversations, they must be allowed to receive
signals too. If this is seen as a problem, we could use
GcrSecretExchange from libgcr to estabilish a protected channel.
(Note though that for example network passwords travel the system bus
in clear text too)

So, what do you think? If there are no major objections, I'll start
working on this soon, to get the login dialog at the same state as now
before the end of the month.

Giovanni