Re: [gdm-list] PAM_TTY / console ownership

["William Jon McCann" <mccann jhu edu>]

On 10/29/07, Ray Strode <halfline gmail com> wrote:
> Hi,
>
> > So it isn't at all clear to me how we can fix this problem in
> > ProductSlave cleanly.  At the time we initialize PAM we don't even
> > have an X Server for the session.  We only create the server in
> > response to user-verified.
>
> What's the primary purpose of ProductSlave?  Is it for autologin?  If
> so, do you see a problem with starting the X server before PAM even
> for autologin?  Some PAM modules, like pam_gnomekeyring, for instance,
> depend on DISPLAY being set to do useful things.  Grant
> pam_gnomekeyring isn't particularly useful for autologin...

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.

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.

Due to the way Xorg works it cannot initialize until it can activate
the VT it will run on.  So, we cannot startup Xorg "it in the
background" while we are using a greeter on another VT.

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.

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

Not sure.


Jon