On 5/2/07, Roland Mainz <roland.mainz at nrubsig.org> wrote: > > $ 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. > > Erm, AFAIK this sounds like a common misconception between the login > profile files and the interactive shell environment files: /etc/profile > and ~/.profile are _only_ sourced for login shells while > /etc/ksh.kshrc+~/.kshrc (ksh93) and /etc/bash.bashrc+~/.bashrc are > sourced for all interactive shells. Note that not all interactive shells > are login shells and AFAIK not all login shells are interactive.
Apparently the definition of login shell vs. interactive shell changed somewhere in the lineage of SUNWssh. A Solaris 9 box running 113273-10 processed $HOME/.profile even when scp was being run. A Solaris 9 box running 113273-11 never processes $HOME/.profile unless an interactive session is used. The following CR seems to be related... 6176256 S9 ssh backporting project > AFAIK the question is now how "ssh" is expected to behave: Should a ssh > session run a plain login shell in interactive mode or just a > (non-login) interactive shell ? The way it behaves now makes it impossible to force a per-user PATH, such as you may want to do in restricted shell environments. For example, if I had previously created /rbin with symlinks to the commands that a person is allowed to use and had an unmodifiable .profile in place, escaping from the restricted shell is non-trivial for the typical user. With the way that it works now, it is trivial to run any command that is in the default (for all users) PATH and bypass a restricted bin directory that was previously imposed. Mike -- Mike Gerdts http://mgerdts.blogspot.com/
