On 5/2/07, Roland Mainz <[EMAIL PROTECTED]> 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/
_______________________________________________
networking-discuss mailing list
[email protected]
