This is a discussion on RE: scp -t . - possible idea for additional parameter - openssh ; > Date: Fri, 12 Oct 2007 09:19:35 +1000 > From: firstname.lastname@example.org > To: email@example.com > CC: firstname.lastname@example.org > Subject: RE: scp -t . - possible idea for additional parameter > = > On Thu, 11 Oct 2007, Larry Becke wrote: ...
> Date: Fri, 12 Oct 2007 09:19:35 +1000
> From: email@example.com
> To: firstname.lastname@example.org
> CC: email@example.com
> Subject: RE: scp -t . - possible idea for additional parameter
> On Thu, 11 Oct 2007, Larry Becke wrote:
> > =
> > On 2007-10-11 18:01, Larry Becke wrote:>> Can this be done? >Theoretica=
lly. See my previous message.I must have missed it.
> > > Is it so terribly hard to add the feature?>It's not easy. See my prev=
ious message, and do a little research on path>canonicalization and past di=
rectory traversal vulnerabilities in, e.g.>IIS and Apache, to understand th=
> > =
> > To throw an error and exit if "../" is in the remote path parameter?
> > To add a "./" between hostname: and /path/to/dir in the remote path par=
> That is probably insufficient and likely to break some software that
> uses scp. You could use realpath(3) and compare the stem, but that has a
> downside too: it will break on traverse-only directories.
Since the change I'm looking for is something that would have to be
specifically selected - instead of using scp -t, using scp -T, this should =
(I won't say won't, because anything is possible) not break any normal use =
Given that we would not actually be changing that expansion in any way,
but doing some very minor work up front, before passing the remote path
on to the unchanged code, I'm still not sure that I see that it would
Again, as part of a pre-processor, activated only if scp were started
with the -T parameter, instead of the -t parameter, would do 2 things.
Scan the remote path for "../", and if found - error out, don't do any kind=
of transfer. Give a simple error message like "Upstream directory traver=
sal not allowed in this mode of operation."
Insert "./" between the hostname and remote directory to make it relative t=
o the startup directory. =
hostname:/some/path/to/dir becomes hostname:.//some/path/to/dir
hostname: becomes hostname:./
I still don't see anything sinister here, however, I may be oversimplifying=
> Just to be clear, I have zero interest in making any feature additions
> to scp and I think most of the developers feel the same way. It is a
> difficult protocol to extend, and its use of a shell-expanded commandline
> to inform it of which files to transfer makes it very brittle. Given its
> very widespread use, I think it is best to leave it be and concentrate
> efforts on making sftp/sftp-server a compelling substitute.
I understand that everyone that has worked on openssh past and present comb=
ined have spent a lot of time making a very nice, clean application that is=
widely used and respected in just about every area computer related.
However, I feel it is unfortunate to freeze scp's features, as sftp/sftp-se=
rver can (to my knowledge) in no way substitute the simplicity that is scp.
I don't see sftp being picked up as an scp replacement until sftp can be u=
sed like scp in a single line.
sftp -f filename user@remotehost:
sftp -f user@remotehost:filename .
sftp -f filename -i keyfile user@remotehost:/some/dir =
sftp -i keyfile -f user@remotehost:/some/dir/filename .
The keyfile could be set to start sftp-server with the -T param (or whateve=
r was chosen to mean, start here, lock upward traversal) and specify a star=
command=3D"/usr/libexec/openssh/sftp-server -T /some/other/path/to/start/in"
Then again, every command sent would have to be parsed to see if "../" were=
used and if so, error.
It would also have to insert "./" into every source path for the get/mget c=
ommands, as well as insert "./" into every destination path for the put/mpu=
Yet, if it took this kind of command line input, then converted it to the a=
ppropriate sftp commands behind the scenes, that might work.
It seems that more work would be involved in this, than scp, but again, I a=
m not a C developer, so maybe I'm totally off base here.
> PS. I don't know what mail client you are using, but it is mangling =
> the quoting in your replies into an unreadable mess.
hotmail, and very few people replying to myself as well as the mailing list=
, meaning that I had to cut-and-paste to reply to most people.
my apologies for the mangling....
Maybe I'm just barking up the wrong tree here, as no one seems (to me anywa=
y), to be willing to see things from someone else's perspective. =
So far I've received "use chroot, it's great and simple." or "use webdav a=
nd ssl - even though you have to work with keys, keystores, install a webse=
rver, utilize wget and probably a whole plethora of things I've not found y=
et" or "use rsync" which unfortunately does not fit into the class of usabl=
e software for the types of scripts and transfers we are currently doing.
It seems odd to me that everyone's suggestion is to "Use someone else's sof=
tware, we don't want ours to work like that." However, being open-source, =
it is your software and you make the final decisions on what does and does =
not make it into the software as a feature.
I've already been hit up by 2 commercial ssh vendors who are eager to imple=
ment the idea, one of which already has some of the functionality built in.=
I hate the idea of going that route, but may have no choice. My apologie=
s for wasting everyone's time reading all my useless posts.
Windows Live Hotmail and Microsoft Office Outlook =96 together at last. =A0=
Get it now.
openssh-unix-dev mailing list