scp -t . - possible idea for additional parameter

[Jefferson Ogata]

Larry Becke wrote:
>> Yes, and...? What does that accomplish in terms of security,>specifically? I.e. what is the specific threat you are trying to protect>against?
>  
> It's pretty simple really, to not allow someone who is copying a file to go anywhere outside of the directory we started them in.

How does that stop them? So they scp it to somewhere under their home
dir, then they ssh in and mv it wherever they want. Or they use sftp.

> Why should anyone have to build out a hugely convoluted chroot'd environment to simply disallow someone from writing / reading from anywhere but their starting directory?   Especially if we can simply, and effectively disallow the use of "../" in the remote file path, as well as preface "./" to the remote path after the hostname.

First off, a chroot environment is not that hard to build.

As to why, uh, because it's an effective way to do what you want that
doesn't require modifying scp semantics.

Another suggestion, however, is to use filesystem permissions, which
should already be set to enforce what you want. They work regardless of
any bugs in scp or whatever canonicalization code you add to scp.

> If this *feature* were able to be set system wide, users who were allowed to scp (ie, change their login shell to be "/usr/local/bin/scp -t .") only would never be able to write outside of their home directories, unless the systems admins had configured sym-links to point somewhere else.

Ah, so you want to use scp as a shell. Most peculiar. Would that even work?

It seems to me you want to add constraints to scp's behavior that may be
difficult to enforce, in order to implement something that is not really
any of ssh's business. Have you tried WebDAV over SSL?

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service