Re: LTSP thin client login through LightDM or GDM

> On Wed, Aug 01, 2012 at 09:07:31AM -0000, Mikael Lammentausta wrote:
> > There has been some discussion on the LTSP developer mailing list
> > about adding supporting for other login display managers than LDM.
> ...
> > Any comments?
> 
> You probably should take a look at Scotty's libnss-sshsock and
> libpam-sshauth
> projects, which were invented with the long-term goal of allowing any
> display
> manager to be used with LTSP:
> 
>   http://bazaar.launchpad.net/~sbalneav/ltsp/libpam-sshauth/
>   http://bazaar.launchpad.net/~sbalneav/ltsp/libnss_sshsock/

The LightDM solution Mikael mentioned is based on libpam-sshauth and libnss-sshsock. As I've been testing it, it works, but there are still some rough edges that required ugly hacks. It works more nicely with pam_krb5 and kerberos tickets a bit better, but both should be doable with some polishing. All the ldm/rc.d scripts, but localapps support, work with no modifications. Current localapps support breaks as it conflicts with nss-sshsock as it syncs getent information locally.

Currently the LightDM hack (https://github.com/opinsys/ltsp-lightdm) works like this:

1. ltsp/screen.d/lightdm sets some env variables and start lightdm (with custom pam config)
2. pam_sshauth connects to the server
3. pam_exec calls the ltsp-session script to open the control tunnel
4. lightdm checks that the user exists through nss (using libnss-sshsock2)
5. pam_exec calls the ltsp-session script to initialize the session on the server and to run the ldm/rc.d scripts
6. lightdm runs a dummy script to keep session open

Right now the control tunnel is created as root in chroot like ldm does it. libnss-sshsock and ldm/rc.d scripts then use that connection to contact the server. Here we run to some problems that Scott mentioned already when he was testing the stuff for the first time:

http://marc.info/?l=ltsp-developer&m=130149333404438&w=2

 * During the "auth" phase, the tunnel's created so that we can bring down the
   passwd, group, and (possibly) shadow entries needed to satisfy xdm.  At this
   point, when the tunnel's created, it's created as root.  By the time we
   progress down to the session phase of pam, and indeed, the session scripts
   in xdm, we've dropped priv's down to the user, making our tunnel useless, as
   it's owned by root.  Oooops.  A simple chown of the tunnel doesn't work (I
   tried).  So, we'll have to establish the tunnel twice: once as root to bring
   down the bits we need during the auth phase, and once as the user to
   actually launch our session.  This will require some changes to the
   shm_askpass helper, since it'll have to keep the password around a while
   longer, and change the permissions on the shared memory segment.  I've
   already got a firm idea in my mind how this will work.

Overall the auth phase gets a bit messy as various components need working nss passwd database and if nss-sshsock is used for that, getting the control socket working early enough is a bit tricky. With fat clients it might be preferrable to open the control socket with user's permissions as Scott suggested. How this should be done is one of the open questions.

I'll keep testing the system further, so I'll post more in a bit.

Happy hacking!

Veli-Matti

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net