[Pkg-ltsp-devel] Bug#747178: ltsp-client-core: ltsp-localapps fails if user's /etc/passwd shell is missing on client

[Vagrant Cascadian]

Control: tag -1 -patch

On 2014-05-06, root wrote:
> I have been debugging why ltsp-localapps was having no effect on my LTSP 
> setup. The problem is that on the server I use /bin/zsh as my default 
> shell, but this is not installed on the client. Obviously I could add 
> all possible shells to the client, but this doesn't make it so 'thin'.

Thanks for reporting the issue!

Sorry it took me so long to test your patch...

> My fix is to add -s /bin/sh to the su command in ltsp-localappsd:
>
> --- usr/bin/ltsp-localappsd	2012-06-27 22:26:21.000000000 +0100
> +++ /opt/ltsp/i386/usr/bin/ltsp-localappsd	2014-05-06 08:28:22.000000000 +0100
> @@ -60,9 +60,9 @@
>  
>          logit "Executing command as username ${LDM_USERNAME}: ${LTSP_COMMAND} "
>          if [ "$LTSP_COMMAND_WAIT" = "true" ]; then
> -            su - ${LDM_USERNAME} -c "LANG=$LANG LANGUAGE=$LANG DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $CLIENT_ENV ${LTSP_COMMAND}"
> +            su - ${LDM_USERNAME} -s /bin/sh -c "LANG=$LANG LANGUAGE=$LANG DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $CLIENT_ENV ${LTSP_COMMAND}"
>          else
> -            su - ${LDM_USERNAME} -c "LANG=$LANG LANGUAGE=$LANG DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $CLIENT_ENV ${LTSP_COMMAND}" &
> +            su - ${LDM_USERNAME} -s /bin/sh -c "LANG=$LANG LANGUAGE=$LANG DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $CLIENT_ENV ${LTSP_COMMAND}" &
>          fi
>      fi
>      reset_xprop LTSP_COMMAND

Unfortunately, this forces the shell for all users, so "ltsp-localapps
xterm" results in a sh prompt, weather the user's shell is in the chroot
or not.

The "su" manpage suggests it should fall back to /bin/sh, though it's
not absolutely clear to me:

   -s, --shell SHELL
       The shell that will be invoked.

       The invoked shell is chosen from (highest priority first):

       The shell specified with --shell.

       If --preserve-environment is used, the shell specified by
       the $SHELL environment variable.

       The shell indicated in the /etc/passwd entry for the
       target user.

       /bin/sh if a shell could not be found by any above
       method.

Looks like /etc/passwd takes priority over the /bin/sh fallback, I
guess.


The localapps code could adjust the shell entry in /etc/passwd if it
wasn't found, but this would have security implications if the user
specified had a restricted shell...


So, for the moment, the recommended workaround would be to install the
appropriate shells in the thin client, or limit your users to shells
also present in the thin client image.

Please follow up with other ideas to resolve the issue, as I do agree it
is an important one...

live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/attachments/20140805/e0478dbc/attachment.sig>