 + Write a binary, repacing "su -l" with it’s own pam configuration name
 + create a hand-crafted array of sleep times instead of using an
   exponential increase.  This is to avoid silly steps like "2, 4, 8"
   and have something more meaningful instead like "0, 0, 30, 30, 60, 60"
 + log when the session is restarted
 + configure via preseeding
 + path is not good for root
 + split X options before passing them to xinit?  Is it needed or xinit does it?
 + signals are blocked while waiting between retries
 + set up the right environment, and cd to the right place
 + does not start X session if it is run as a user
   X: user not authorized to run the X server, aborting.
   (allowed_users=console in /etc/X11/Xwrapper.config)

Notes on another way to implement display managers:

#debian-devel < enrico> so, /etc/X11/Xwrapper.conf disallows a user to run X unless they're on console.  How do display 
                        managers work around it?
#debian-devel < jcristau> they're root.
#debian-devel < enrico> jcristau: but don't they sudo to the requested user before starting X?
#debian-devel < jcristau> there's no requested user before starting X
#debian-devel < enrico> jcristau: uhm, no they don't
#debian-devel < enrico> jcristau: I'm writing a display manager that performs autologin, so I know what user I want 
                        before starting X
#debian-devel < enrico> jcristau: I thought that becoming the user and starting X would be enough, but it isn't.  
                        Apparently, I need to start X passing myself as the session, and then become the user
#debian-devel < jcristau> so they start an X server, and after you enter your login/pass they fork, setuid() and start 
                          your session, basically.
#debian-devel < jcristau> uh. 'start X passing myself as the session'?
#debian-devel < enrico> jcristau: like, run xinit myself -- options
#debian-devel < enrico> jcristau: and then myself will take care of setuid() and running Xsession
#debian-devel < enrico> jcristau: sounds sound?
#debian-devel < jcristau> possibly
#debian-devel < enrico> jcristau: thanks!
#debian-devel < jcristau> (or you could do what xinit does yourself, so you can deal with X exiting if you want)
#debian-devel < enrico> jcristau: what does xinit exactly do?  I'll get the source code and see
#debian-devel < enrico> jcristau: uhm, xinit actually does quite a bit of things
#debian-devel < enrico> jcristau: nontrivial signal handling, start X server, wait for it to accept connections, 
                        workarounds for several insane bits
#debian-devel < jcristau> enrico: hmm. set up a SIGUSR1 handler in the parent to know when you can start the clients, and 
                          signal(SIGUSR1, SIG_IGN) in the child. not that horrible. no idea about the other insane bits :)
#debian-devel < enrico> jcristau: xinit also polls with XOpen to see if it came up, sets a sigalarm for a 15 seconds 
                        timeout for it to come up, has more signal mojo that I didn't stop to grok
#debian-devel < enrico> jcristau: then it has to juggle two processes.  In the end, if I reimplement that I risk 
                        introducing more bugs than it's worth, and I can just reuse xinit and give it a session that does 
                        the setuid

 - we currently do not honour login.defs.  Do we need it?  no

