add scp path to _PATH_STDPATH

[Ishikawa]

Looking at the discussion,
I initially thought that adding a command option to
specify where the expected program would be found might help.

Naturally, this poses new problems.

- suppose the user doesn't know the non-standard path name.
- what if the user specifies the totally unrelated path for, say, scp?
    We should not be fooled to run a file specified user
    so easily.

The second question above might be solved using a scheme
similar to the restricted shell that comes with sendmail.
The restricted shell that comes with sendmail only permits the
execution of files under admin's control. From what I recall,
if I say, for a response to an e-mail delivery run the following file,

    /whatever/the/intermediate/path/is/vacation

the restricted shell picks up the last element of the pathname
and perform look up under a pre-specified directory, say, /var/adm/sm
Under /var/adm/sm, we make entries for permissible programs as in
    vacation -> /usr/ucb/vacation
or whatever.
The restricted shell ignores the intermediate path and only uses the
last filename component to pick up the final executable.

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 [, ...]

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..

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.