Re: [gdm-list] GDM - gdmdynamic and Sun Ray support

[Bob Doolittle <Robert Doolittle Sun COM>]

William Jon McCann wrote:
> That is really unfortunate.  Do you expect this to change?
>   

We're thinking about how much we can Open Source at
this time.

> > In a small nutshell (and focusing on the DM/X
> > interactions), there is a "DDX" driver in the X
> > server that simply generates the necessary
> > rendering protocol and handles keyboard/mouse
> > event protocol directly over the network to a thin
> > client (and miscellaneous things like monitor
> > power management and LEDs).
> >
> > SRSS handles rendezvous with a new thin client
> > when it connects to the server, and if no X
> > session yet exists and one is required it will use
> > gdmdynamic to tell the Display Manager to create a
> > new X session.  It will also put necessary state
> > information on the system for the DDX to use to
> > connect to the thin client when the X server
> > starts up.
> >     
> What is the necessary state?
>   

Things like a unique session-id, display number,
user identifier (what we call a "token" which can
be derived from a smartcard inserted in the device
or other sources).  That's all that's needed to
create the association between a particular X
server and a particular thin client (as long as
the thin client isn't configured to participate
with other thin clients in a multihead
configuration).

The X server DDX knows what display it is serving,
and with that at startup can determine its system
session-id and register itself with SRSS to
receive connection events for its session that
contain the thin-client IP addresses.

SRSS knows how to match up the system session-id
with the user's session identifier ("token") as
reported by a thin client, and generate the
connection events to the registered X server DDX.

Some of this is done with on-disk files, some is
done with runtime daemons.

All gdm has to do is to create or tear down an
X server for the specified display number, SRSS
will do the rest.

> > If an appropriate X session already exists, SRSS
> > simply tells the DDX directly to connect the thin
> > client to it and gdm is not involved.  It simply begins
> > rendering to the new thin client.
> >     
>
> How do you determine if an appropriate session exists?

We keep state of the existing system session-ids
and services (like the X server DDX) registered
for them.  When a thin client connects we map the
token reported by it to the system session-id, and
generate connection events to all services
registered for it (like the X server DDX), and
they do their thing (like start rendering to the
thin client).

> How do you
> disconnect the user session?
> How do you indicate to the user session
> that it has been disconnected?
>   

If a token is dissassociated from the thin client (e.g. the
user removes their smartcard) it will generate a protocol
event to the server indicating a disconnection, which will
be again matched as above and a disconnect event will
be sent to all registered services (like the X server DDX).

> > Our thin client also handles audio and USB devices
> > but none of that involves gdm in any way so it's
> > not relevant.  Happy to discuss it if interested, however.
> > Suffice it to say that this is handled directly from user
> > space to the thin client over the network when possible,
> > aided by some trivial loopback drivers and some mass
> > storage glue (quite a bit less trivial).
> >     
>
> So do you not have any kind of HAL support for / awareness of client
> side devices?
>   

I don't believe so.  Remember we support other OSs than Linux (like
Solaris, for instance :).  I don't know our plans in this space.

> How do you handle policy for, permissions of, and sharing of devices
> on the server side?
>   

Rather complex - do you really want to go there? :)

Essentially we use the gdm instrumentation I
described before (the gdm.conf
PreSessionScriptDir, PostSessionScriptDir, and
DisplayInitDir hooks) to keep track of user state
changes as well as the connect/disconnect events
to registered services (some of which manage
devices), and update permissions and setup/tear
down devices nodes accordingly.  I believe our
device daemons create/destroy device entires
directly, not sure if HAL is used.

For things like libusb no device nodes are required.
The apps handle devices directly without going
through the kernel.  We control app visibility to
devices through the registration and mapping
mechanisms mentioned above.  Apps within a
given session can see and access all devices
connected to the thin client which is associated
with that session.  libusb doesn't support a finer
access control model than that.

Not mentioned above are a number of security
measures to force users to authenticate before
connecting to a session, and other security
features you'd expect to deal with MIM, DOS,
and similar attacks.

We also support a PAM-based Kiosk model
for customers that want unauthenticated, anonymous,
controlled access to desktop sessions.

-Bob