Re: Updated xrexecd.sh

(Writing this to the list because it is lame that we're doing this in 
private.  From now on I will NOT RESPOND to private mail that should be 
done in public.)

Gideon Romm wrote:
> 
> 
> On Wed, Aug 6, 2008 at 10:31 PM, Warren Togami <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Gideon Romm wrote:
> 
>         Here-
> 
>         This one test nicely on Ubuntu and has a "sleep 2" put in to
>         make it CPU friendly.
> 
>         -Gadi
> 
> 
>     This version of the script somewhat works but there are three major
>     problems.
> 
>     Test Procedure
>     1) install xterm in your chroot
>     2) LDM_DEBUG_TERMINAL=yes
>     3) Add "set -x" near the top of the script so you can see what
>     happens.  Then run xrexecd.sh manually in the local terminal.
>     4) Kill any running xrexecd.sh in the background.
>     5) From a terminal running on the server, xrexec to run xterm.
> 
>     1) I need "xhost +" for it to succeed to run any program.  Example:
>     + echo "Executing the following command as test: /usr/bin/xterm '
>     + su test -c /usr/bin/xterm
>     No protocol specified
>     /usr/bin/xterm Xt error: Can't open display :7.0
> 
> 
> Do any of the following also work?
> 
> a. xhost +localhost

This of course works.  I think we really shouldn't accept this though, 
unless we completely kill the idea of having multiple screen sessions 
running simultaneously.  Even then this would be a distasteful thing to do.

> b. chmod a+r /root; chmod a+r /root/.Xauthority
>  

Turns out this doesn't make any difference because su seems to be 
blanking out a few environment variables like XAUTHORITY and HOME.  From 
"man su" I found the -m option so I added that to xrexecd.sh.  Strangely 
enough, many other environment variables like LDM_SESSION, LOCAL_APPS, 
LDM_SOCKET survive through the su.

Sadly, -m still unsets HOME and XAUTHORITY so it is impossible for the X 
clients run through this to work properly.

I then tried to make the X clients use the user's own $HOME/.Xauthority 
file.  This failed because HOME is unset, so it couldn't find it at the 
default location.  Even after manually setting XAUTHORITY to 
/home/username/.Xauthority, it fails because xauth locking seems broken 
over sshfs mounts.

So we need the following...

Non-root users need access to the client system's .Xauthority as a local 
file.  /root/.Xauthority is the current location.  This is a bit messy 
because the permissions on this directory on Fedora are 0700 by default. 
  I was never comfortable with this hard coded location to begin with. 
I might propose we change this in the following way:

    * XAUTHORITY=/var/run/Xauthority-randomstring
    * /var/run/Xauthority-randomstring permissions 0600
      S01-localapps uses setfacl to allow only LDM_USERNAME access.  So 
other possible logged in non-root users can't screw with it.
    * Figure out some way to pass this XAUTHORITY into the su launched 
environment.  We also need a way to set HOME which currently isn't set 
for some reason.

> 
>     2) sshfs mount of /home/username succeeded, however the default is
>     to disallow other users (root did the mount).  I added -o
>     allow_other to the sshfs mount command in the rc.d script and it
>     seems good now.  I'm checking this into bzr.
> 
> 
> Good catch.  Is it better to do "allow other" or to do the mount as the 
> user?

Mounting as the user might be possible, except then the user needs 
access to the socket.  allow_other relies on standard UNIX permissions 
so should be good enough?

>  
> 
> 
>     3) xrexecd.sh blocks waiting for the launched app to exit before
>     continuing its loop.  Is this intentional?
> 
> 
> Good point.  We may want to let the user run more than one local app at 
> a time.  :)  We should be safe adding an '&' to the end of the "su" 
> command to execute LTSP_COMMAND in the background.

The current 2 second delay is a bit long, yet a smaller delay makes it 
use too much CPU and causes unnecessary wakeups.  I think this shell 
script is a good proof of concept.   But ultimately we need to find a 
better way to signal than atoms, since atoms require constant polling.

Warren Togami
[email protected]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_____________________________________________________________________
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