>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 environmen=
t to simply disallow someone from writing / reading from anywhere but their=
starting directory? Especially if we can simply, and effectively disallo=
w 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 t=
o scp (ie, change their login shell to be "/usr/local/bin/scp -t .") only w=
ould never be able to write outside of their home directories, unless the s=
ystems 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=3D"/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 int=
o the startup directory.

A simple (I hope) change to modify the remote path params, would finish thi=
s and make it extremely easy to lock the file transfer to the start directo=

__________________________________________________ _______________
Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop =
by today.
openssh-unix-dev mailing list