add scp path to _PATH_STDPATH

[mouring at etoh.eviladmin.org]

On Sat, 3 Mar 2001, Ishikawa wrote:

[..]
> But this is a little complicated.
> 
> I think a good solution would be define a new entry
> in the sshd_config file which would be something like
> 
>     PATH  subsystem-name  full-path-to-the-executable [, ...]
> 

v2 protocol has no issues with this.  Since 'subsystem' defines out
such things (One could more then likely tweak scp to work as a
'subsystem' with every little effort).

Pretty much your suggesting adding the same style of feature to v1.  I
really don't know if I like the idea since it attempts to shoe horn two
different concepts.

Attempting to 'guess' the users intent is not always a good thing.


> and honor the entry when we look for the binary.
> Instead, a la sendmail/rsh combination, we might introduce something lile
> 
>    EXECDIR  directory-where-symbolic-link-of-subsys-exec-is-found [, ...]
> 
> eg.
> PATH  scp       /usr/local/bin/scp
> 
> PATH   sftp       /usr/local/bin/sftp
> 
> or
> 
> EXECDIR   /usr/local/bin
>    (from which scp, or sftp or whatever is picked up.]
> 
> I allow a possibility of specifying multiple pathnames or directories
> just in case. The directories
> need to be checked to avoid trojan horse being implanted.
> But usual sanity checking  about
>    - owned by root,
>    - no rwx permission to others, etc..
>    - the intermediate path to the final executable
>       not group writable or world-writable, etc..
> 

ssh '/path/to/scp file machine:file'  .. Do we really want to strip
the '/path/to/' off of that line and replace it with our path?  how
do we know that /path/to/  is actually right?  It could be a modified scp
that is in a different directory for a special task (not saying it's wise
=).  Do you really want to remove the ability of the end-user to 'fix' scp
if the ISP/shell provider has a broken one?  Maybe I wrote an add-on to
scp and I wish to use my special version bewteen home and my
ISP?  Changing standard behaviors is touchy.


> should suffice. (Come to think of it, does sshd
> check for this currently???)
> 
> Shouldn't such entries in sshd_config solve the problems discussed?
> (Or do we need a similar entry for ssh_config as well?)
> 
> I, for one, was a little uncomfortable to add /usr/local/bin
> to the default-path spec when I found out that I needed to re-compile
> sshd to search /usr/local/bin for scp: I had put scp under /usr/local/bin
> somehow
> and realized that I needed to let sshd know that scp is there.
> 
> 

Solutions:

a) Back-port 'subsystem' concept to v1  .. Never will happen
b) Fix up the path and ignore the problem.
c) add support for scp as a subsystem for v2 and dump v1 support.
d) Add some complex hack that could cause things to not work as the user
expects them to under certian cases.

I'm more in favorate of (b) and (c).   (I believe Markus stated it would
be an interesting project to do a 'scp2' emulation.  scp over sftp.  Which
after looking at our current sftp client it would be pretty easy to
do.  Minus the 'scp site:file site2:file' concept. =)

- Ben