scp -t . - possible idea for additional parameter

Larry Becke guyverdh at
Thu Oct 11 04:50:29 EST 2007

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

More information about the openssh-unix-dev mailing list