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

[Giovanni Campagna <scampa giovanni gmail com>]

2012/5/2 Ray Strode <halfline gmail com>:
> Hey,
>
> (sorry for the slow response)

Nah, no hurry yet :)

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

Right, and I see there is no way to limit which applications can
listen to which signals using the message bus policy. This means we
need a private channel.

> 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.

You need a dynamic bus name, because you can have multiple slaves at
the same time.
I thought of SeatId because session applications have XDG_SEAT in the
environment, and because a slave conceptually maps to one login, or
seat.

> - Multiple sessions can be running at the same time on the same seat

Right, what we actually want is $XDG_SEAT-$XDG_VTNR (or something
unique enough). $XDG_SESSION_ID can't work, because it's not stable
between consecutive logins.
(All this is assuming a systemd/logind environment - OSes using
consolekit will need to find some other identifier or populate those
variables, I guess)
Alternatively, we could use X display name (so
org.gnome.DisplayManager.Slave.0 for :0)

> - 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.

I think we want to keep org.gnome.DisplayManager for now. If any, it
helps with gdbus-codegen to have one prefix for all interfaces.

> - 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.

Right, agreed.

>> 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?

I didn't want to use object paths because those are exposed by
o.fd.DBus.Introspection, and I wanted the conversation id to be like a
capability to skip checks after OpenConversation. It becomes moot if
we agree that OpenConversation should just return a private dbus
address (or even better, no address at all, and pass one socketpair()
end)
Anyway, what I had in mind essentially would be checking that the
requestor process is in a session controlled by the slave (via
loginuid or cgroups, I guess).

>> - 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.

Ok.

>> - 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.

Yep, probably it's not wise to trust dbus if signals are broadcasted
to all clients by default.

>> 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.

Ok. It shouldn't be difficult to add it on top of the existing
interface (if a libgcr dependency is ok for gdm)

Giovanni