Bug 959

Summary:

enhancement: supporting a remote scp path option in scp

Product:

Portable OpenSSH

Reporter:

dave <dlssh>

Component:

scp

Assignee:

OpenSSH Bugzilla mailing list <openssh-bugs>

Status:

CLOSED WONTFIX

Severity:

enhancement

Keywords:

openbsd

Priority:

Version:

-current

Hardware:

All

OS:

All

Attachments:

Description	Flags
patches scp.c and pathname.h	none

Description dave 2004-12-04 02:36:11 AEDT

I've written some enhancements to scp.c and pathnames.h to enable the scp
to arbitrarily set the remote scp path.
(eg $ scp -e /usr/bin/scp foo user@bar:foo)

I did read the "scp: command not found" FAQ entry but I'm not quite sure
why we can't do this, unless it's because enhancements to scp are no
longer a priority.  Any other reason why it "is the way it is" other than
that?

The patch is below, all I've really done is replaced char cmd[CMDNEEDS]
with char *rspcmd throughout.  Forgive any dodgy coding, I'm not a
developer during the day :).  I haven't been able to test the patch below
because I don't have a handy openbsd box, I have tested a patch under the
portable version that seems to work fine.  Let me know if I'm better off
providing that.

My reason for wanting is that it means server side scripts that wrap
around forced commands can tie scp down to the absolute path. 
Incidentally, if there is a reason why anyone thinks this is a bad idea,
please let me know.

Comment 1 dave 2004-12-04 02:39:46 AEDT

Created attachment 745 [details]
patches scp.c and pathname.h

i don't think these two files have changed much since I created this patch
(31/8/2004), so it should be fine to patch directly against the current openbsd
openssh tree.

Comment 2 Damien Miller 2004-12-06 16:44:34 AEDT

I'm not sure that we should add more scp options, when a user can just fix the
server's $PATH. scp has required a working $PATH for many years and has survived
without this.

Comment 3 dave 2004-12-06 17:36:19 AEDT

My reason for wanting is that it means server side scripts that wrapper
forced commands can tie scp down to the absolute path.  

When scp is executed is PATH being determined by the user shell (by virtue of
the fact that sshd is doing a sh -c force_cmd)?  In a restricted environment
this would allow me to pattern match against the SSH_ORIGINAL_COMMAND, and I
would rather be matching against an absolute (^/usr/bin/scp...$) command than a
relative one (^scp...$).  Perhaps my fears wrt relative path are unfounded..

Maybe this is unnecessary?
a) because it isn't possible for a user to abuse the PATH variable; or 
b) because the PATH variable can be forced in .ssh/environment

I fine with this patch being rejected if there's a better way to achieve what I
want to do.

Comment 4 Damien Miller 2004-12-07 11:59:27 AEDT

Reading of ~/.ssh/environment is controlled by the PermitUserEnvironment option
in sshd_config. It defaults to "no". 

The other ssh-related vector by which the environment may be modified by the
user is through environment passing (AcceptEnv in sshd_config, SendEnv in
ssh_config), it too is off by default (on both the client and the server).

So, assuming that the user can't modify shell initialisation files (e.g.
.bashrc), the user's $PATH is under your control and you should be able to match
on the bare command safely.

Comment 5 Darren Tucker 2006-10-07 11:38:06 AEST

Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.