Re: [gdm-list] PAM_TTY / console ownership

["Ray Strode" <halfline gmail com>]

Hi,

(sorry for the delay I got pulled into an Fedora 8 thing yesterday)

> The GdmProductDisplay and associated GdmProductSlave are created on
> demand by a GdmFactoryDIsplay.  The idea is to have a dedicated
> greeter and launch the user session on another Display/VT.  It is
> essentially an experiment but one that I think makes a lot of sense -
> particularly when we get kernel mode setting.
Oh, this is for that.  That makes sense.

> So, there are a few things that make this somewhat tricky.  In older
> versions of GDM we tried to pick the VT value for Xorg instead of
> letting it find one.  There were a few problems with this.  For one,
> we couldn't guarantee that we would actually get that value.  And this
> actually happens quite a bit.  I think it is better to let Xorg try to
> get one.  But of course that only happens after Xorg starts.
What we might be able to do, is take the VT, hold on to it, and then
when Xorg tries to get it release the VT.

What I mean is, at some point Xorg must do ioctl (fd, VT_ACTIVATE) and
then later block on ioctl (fd, VT_WAITACTIVE).  When it does the
VT_ACTIVATE, if we control the VT it's trying to change to then we'll
get signaled asking for permission to change to the VT and I think X
will just wait on the VT_WAITACTIVE call until we release the VT.  We
might be able to look at the extended siginfo of the signal to make
sure its our X server asking for the vt change.

That's the theory anyway.  I don't know if it'll work.  If it did
work, then X will still block until authentication is complete, but we
would be able to guarantee it gets the VT we want it to get.

> So, in order for this all to work, I guess we'll need to somehow
> "acquire" the VT device and DISPLAY value before Xorg initializes the
> display.
DISPLAY seems harder to know ahead of time,  since it can map to a
port, or a socket in /tmp/.X11-unix or to an abstract socket of the
form \0/tmp/.X11-unix/Xn

Even if we checked all those ahead of time and found a number that
doesn't clash, there's no way to reserve the number for our X server
so there's always a race.

Seems hard to be robust here.

> Perhaps that means:
>  1. we try to hold a lock on the VT until we release it to Xorg
>  2. we make Xorg startup and acquire the devices but wait for a signal
> before initializing the display
If I'm right, 2 shouldn't be necessary. It might just block until we
give it the vt.  I'll need to experiment.

Anyway, we can think about the factory stuff a little later.  Right
now let's get the more conventional setup working.  I'll look into the
"not running through Xsession, so not getting ssh-agent, dbus-launch,
/etc/X11/xinitrd.d/*" issue.

--Ray