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

[Ray Strode <halfline gmail com>]

Hey,

(sorry for the slow response)

On Sun, Apr 29, 2012 at 12:10 PM, Giovanni Campagna
<scampa giovanni gmail com> wrote:
> 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.
Right, makes sense.

> So, my question is, is there any particular reason why gdm-simple-slave uses a
> private DBus server instead of the system bus?
I didn't write the initial code (Jon did), but I can try to answer
anyway.  I guess he'll chime in if he has something to add. A couple
of reasons spring to mind:

1) normal users can monitor the system bus for activity.  In
particular, out of the box, they see all signals flying around. We
don't send the users password via signal, but we do send requests from
the pam module.  The conversation between the pam module and the user
is personal, and so it's probably good practice to not expose the
questions and comments of the pam module to other users on the system.

2) The communication has historically been strictly between parent and
child, so setting up peer-to-peer communcation was straightforward

> If not, my plan is to make gdm-simple-slave grab
> org.gnome.DisplayManager.<SeatId>.Slave on the bus and export
> /org/gnome/DisplayManager/GreeterServer there.
So a few thoughts:

- SeatIds are dynamic, they contains uuids in them, and dynamic bus
names don't work to well.
- Multiple sessions can be running at the same time on the same seat
- The name DisplayManager is making increasingly less sense.  We're
generalizing the interface, so maybe we should give that interface a
more appropriate name ?  AuthenticationManager ? LoginAuthority ?
Ultimately, (but not necessarily near-term), it may make sense to
separate the "starting X servers" and the "authentication" parts of
GDM into separate components.
- As mentioned above, I think it's better to keep the conversation
unmonitorable, so it may make sense to just use the system bus to
start things off, and quickly jump into peer-to-peer communcation.

> 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
Maybe conversation should be broken out into a first class object ?
What specifically do you have in mind for permission checks?

> - signals TimedLoginRequested, DefaultLanguageNameChanged and
> DefaultSessionNameChanged would be sent to all clients (or perhaps
> moved to a different interface)
These are very login screen specific and so should probably be on a
separate 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.
Oh I see what you're saying.  The idea being you set a specific
destination on the relevant signals and so it wouldn't be multicast
over the bus, but directed to just the specific client.  That probably
prevents dbus-monitor type snooping and the initial problems I had in
mind.  Still, I think I favor doing things over a separate
communication channel to be more robust against mistakes.

> 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)
I think doing that sort of thing is useful and probably worth doing
for password responses at least.

> 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.
Sounds like you're really on top of things.  I'm glad you're involved
on this project!

--Ray