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

__________________________________________________ _______________
Help yourself to FREE treats served up daily at the Messenger Caf=E9. Stop =
by today.
http://www.cafemessenger.com/info/in...DTXT_TAGLM_Oc=
tWLtagline
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev