scp -t . - possible idea for additional parameter

[Larry Becke]

>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.
 
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.
 
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.
 
Using keys, you could potentially allow a user to scp files to/from another directory, without having to create additional userids.
 
command="/usr/local/bin/scp -t /some/path/to/write/to" .....public key.....
 
within the authorized keys file would do the trick nicely.
 
We can use this functionality today, minus the ability to lock the user into the startup directory.
 
A simple (I hope) change to modify the remote path params, would finish this and make it extremely easy to lock the file transfer to the start directory.
 
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Café. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline