scp -t . - possible idea for additional parameter

[Larry Becke]

>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.
Let's see.... The users that would be given this feature, wouldn't be given a password for their login.  ie - they are required to use their key.
Their login shell (in /etc/passwd) would be /usr/local/bin/scp -T ./data
Their key would be locked via "command=" to running the same scp -T ./data command
 
Their authorized_keys file would be read-only.  Their .ssh directory would be read only.
Their home directory would be read-only.  
There would be a "data" directory under their home directory that is the only thing writeable.
>As to why, uh, because it's an effective way to do what you want that>doesn't require modifying scp semantics.
Really?  How is it effective if you have to copy libraries to every users' home directory structure in order to allow them to use chroot'd code?
 
chroot cannot be run as anyone but root, so you cannot use it in the "command=" section (i've tried).
 
>Ah, so you want to use scp as a shell. Most peculiar. Would that even work?  Yes - it works very well, except that it doesn't restrict the user to their home directory.
 
>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?
I want to add a simple parameter parse that errors out if "../" is in the remote path, and adds "./" between the host segment and path segment of the remote path.
 
I'm not asking to *enforce* anything.  I'm not asking for tons of changes to watchdog anything.  I'm only asking for a very simple front end change that takes effect when scp is started with "-T" instead of "-t".
 
Simple administrative tasks and permissions will take care of the rest.
 
It's a very subtle change, one that won't impact anyone who uses scp in it's default manner, and would give admins a very simple and effective tool to restrict secure file transfers (ie production system transfers - not day to day users) to the directory we designate as the remote source/destination.
 
Whether or not you can see the need for something like this, or agree with my reasoning for this, I'm asking simply, can it be done?  What harm would there be in adding it?   
 
 
 
_________________________________________________________________
Climb to the top of the charts!  Play Star Shuffle:  the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct