Between the days of Solaris 9 and today, the behavior of .profile processing through ssh has changed. It used to be that users could customize their environment through .profile and they would get the same behavior whether they did:
$ ssh hostname user at hostname$ mycommand OR $ ssh hostname mycommand The move to Solaris 10 broke this. The apparent backport of the Solaris 10 ssh to Solaris 9 (delivered via patches) broke this on Solaris 9. Aside from specifying full paths to commands (or transitioning to bash where .bashrc is processed in all cases), there seems to be no easy solution for per-user shell customization. There are two areas where this causes problems: 1) Normal users that want/need to tweak their environments, as described above. The trivial answer is to tell the user to specify the full path to the command. However, if the command's location is not consistent between servers (e.g. Solaris 9 /usr/local/bin, Solaris 10 /usr/sfw/bin), you start to get into telling users to do things like: ssh somehost env PATH=/usr/bin:/usr/sfw/bin:/usr/local/bin somecommand OR ssh somehost '. $HOME/.profile ; somecommand' Both are yucky because it exposes too much complexity for something that should just work. 2) In some cases, users have been configured to have restricted shells along the lines of # useradd -d /home/user -s /bin/pfksh user # mkdir /home/user # chmod 755 /home/user <<<< still root:root # vi /home/user/.profile <<<< set custom PATH; cd writable # chmod 444 /home/user/.profile <<<< user cannot modify it # mkdir /home/user/writable # chown user:group /home/user/writable ... set up ssh keys, etc. With the current behavior with regards to .profile processing, this means that I have to use "command=..." in .ssh/authorized_keys to specify a wrapper script to invoke the requested command (e.g. scp for file transfers to the machine). Do others see the current behavior of .profile processing as broken or good design? Do other workarounds (for what I see as problems) exist that are a bit more elegant while still providing per-user configuration? If the answer to either question seems to be "no", I would propose that this be added to the list of things that this project should tackle. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
