Re: scp -t . - possible idea for additional parameter‏

[Larry Becke]

>> I understand that that is not how scp works today.>And it will likely never change.
Why not?  Just because "That's how we've always not done it" doesn't sound like a very good reason to me.
>> I'm suggesting that we make a minor change to how it works.>scp is maintained for compatibility reasons only, as I've understood>things.
That's still not a valid reason to not implement a very simple change.
>> I am suggesting this will make it trivial to secure one subset of>> the system.  That subset being scp.>Moot point unless scp is the only way users can use the system, which>I don't think is the case all too often.
In my specific case, it is the point.   I'm using a public key authentication, where the parameter defined in the authorized_keys file is
 
command="/usr/local/bin/scp -t /some/path/to/dir" ....remainder of key....
>Either you're prepared to make an effort in order to make the system>secure, or it doesn't matter. Hacking up scp is good for neither. :\
Why should *everyone else in the world* have to go through all the hassle of trying to make a "secure" product secure, when a very simple fix, would effectively lock scp so that it couldn't go anywhere above the directory specified in the startup with the -T (like -t) parameter.
 
The simple change outlined would truly make scp *secure* from all perspectives, as opposed to only being secure via the transport.  It could be a significant feather in the cap of the project.
 
If the -T were configurable to be a selectable (either through the build process, or the sshd_config file) all scp transfers could be locked into the user's home directory, which wouldn't be a bad thing at all for those who would want it to be that way.
 
 
Larry
_________________________________________________________________
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