Re: [gdm-list] [RFE] A modular gdm greeter

[Brian Cameron <Brian Cameron Sun COM>]

Ray/Simo:

> The hard part comes when you want to support two or more exotic things
> at the same time in arbitrary order.  Since pam starts at one module
> in the stack and moves on to the next and the next.  Like I said
> above, if one the things is username, it's easy.  You just make the
> top module in the stack ask for a username and punt to the next
> module.  username is special in this regard, though, because pam_start
> takes a username as an argument, so PAM modules are expected to handle
> it being around when they start up.

The big problem here is that most solutions that people use today
for supporting this "multiple things at the same time in arbitrary
order" situation involves the need to restart the program that is
handling the PAM stack (either with the same or a different PAM
stack).

Stable GDM supports this, to a degree, by allowing you to specify
PamStack on a per-display basis, so a controlling daemon or module
can tell GDM that a different PAM stack is needed for a given
display (by hacking together a per-display configuration file with
the right PamStack setting).  Then by simply killing the slave
daemon associated with a display and allowing the daemon to remanage -
and it will pick up the new per-display PamStack value for this display.
Things should work.

Note that using stable GDM today you could probably trigger such
restarting via a GTK_MODULE today, if the gdm user has permissions
to get the information it needs to know that a PAM restart is needed
(e.g. a SmartCard has been inserted or a finger has been placed on
the fingerprint reader).  If you require root permissions to get
this "trigger" information, then I'm not sure how well this would
work as a GTK_MODULE run with the GUI.  Remember that the GDM GUI's
run as the gdm user.  You could, I suppose, also have modules that
you run with the daemon to manage things that require root
permissions, but this could get complicated.

I'm not sure how well the new D-Bus version of GDM supports (or will
support) this sort of thing, but there is likely still a need to be
able to control the PamStack on a per-display basis, and to have some
mechanism to restart given displays with a different stack on
demand.  If we were to redesign this so it works better, perhaps
we could address the two main design flaws with the existing design:

1) Restarting the greeter does cause some flickering, which is
   probably ugly.  Probably would be better if the GDM daemon were
   smart enough to accept some signal or message that would tell it
   to just tear down and re-setup the stack without needing to
   kill and restart the whole greeter and slave daemon.

2) This solution may work for GDM, but you probably need other
   custom solutions for other programs that require authentication,
   such as the screensaver - if you want those to work the same way.

   In other words, this does break the model that "you really shouldn't
   have to do anything outside of PAM to make authentication work".
   But perhaps supporting "multiple things at the same time in
   arbitrary order" case isn't really possible without some smarts
   in the programs that handle authentication.

   If such smarts are needed across multiple authentication programs,
   it would probably be good to figure out what those smarts should be
   so that more of an effort to update such programs in a consistent
   way.

Two proposed solutions include:

1) Make a better interface to tell GDM to simply restart the PAM
   conversation with a given stack.  Then something (perhaps a "GUI
   module or a separate daemon) could signal that GDM should restart
   with the new stack.  This is similar to what we have today, but
   nicer.
2) Allow "GUI modules" (perhaps like GTK_MODULES) which manage their
   own PAM stacks, so you have one stack running at the same time
   for each device.  This PAM stack could be in a separate process
   or not.

> Anyway, I'm not sure what the right solution is to be more flexible.
> Multiples simultaneous stacks sound reasonable.  I don't like the idea
> of more than one stack in the same process at the same time.  PAM
> modules tend to do nasty things, so they really need to be running in
> their own process isolated from everything else (it makes sense
> anyway, because you want to already be fork()'d before you
> pam_open_session).

If a PAM module does such ugly things, it is a bug in the PAM
module.  Some might argue that the right thing to do would be to
fix such broken PAM modules rather than making all programs which
use PAM workaround bugs in various PAM modules.  But I don't have
strong opinions here.

> So, I think Brian's idea of multiple subprocesses, one-per-stack is
> probably the best way to go, assuming multiple stacks is the best way
> to go.

Probably the nicest thing about this approach is you avoid the
need to shut down and restart the PAM stack.  So, this approach
is nicer in terms of managing PAM.  But this makes things more
complciated for GDM.  To do things this way, you would need:

1) Some mechanism for the GUI module to plug into the daemon
   PAM code in a way that wires never get crossed between
   different PAM conversations.
2) The daemon would need to keep track of all the PAM conversations
   if one successfully authenticates, it needs to shut down the others
   and go on with the user session.

I imagine this is possible, but coming up with good/clean interfaces
for supporting this is probably the hardest part.  If someone wanted
to prototype something, then this would be a good starting point for
further discussion, I think.

Brian