scp -t . - possible idea for additional parameter

[Larry Becke]

Yes, this is the same person who never replies back to me, so that I have to cut and paste their responses....     
 
Thanks ever so much.
 
On 2007-10-12 04:12, Larry Becke wrote:>> Maybe I'm just barking up the wrong tree here, as no one seems (to me anyway), to \>> be willing to see things from someone else's perspective.>No one has any trouble seeing things from your perspective. It's exactly>the other way 'round. If you would take the time to understand why>"erroring out" if "../" appears in a path and prepending "./" to the>path will handle only a small fraction of the problem space, arguably>creating more problems than it solves, then maybe there would be some>perspective sharing going on. This advice is not meant merely to rebut>your scp suggestion; it's important to understand how paths can lead you>astray before you try to use simplistic analysis of their string>representations to constrain user activity.
Whoa here - a small fraction of the problem?   What problem are you refering to?  
You keep repeating this like a mantra, yet share no example of problems this could cause.
Again, controlled destination directories that are not mount points, don't have sym-links, permissions would be set appropriately.
scp cannot copy sym-links as sym-links so none could magically appear in the directory, so that is moot.
since we would not be able to navigate up the directory chain, any attempts to do so would error out, and all pathing is now relative to the starting directory, I really don't see the problem.
Again, this would all be done before the rest of the parameter code is executed.  I would assume that pathing problems are already accounted for in the code, and anything that could be a problem would be detected.  
>> So far I've received "use chroot, it's great and simple."  or "use webdav and ssl - \>> even though you have to work with keys, keystores, install a webserver, utilize \>> wget and probably a whole plethora of things I've not found yet" or "use rsync" \>> which unfortunately does not fit into the class of usable software for the types of \>> scripts and transfers we are currently doing.>Given your tendency to employ biased, deliberate misquotation in an>argumentative way, coupled with your unwillingness to accept the>challenge of learning some fairly mundane sysadmin tasks (e.g. set up a>WebDAV service, set up an SSL web service, set up a maintainable chroot>hierarchy, learn how to use chown and chmod or even chattr), it's no>wonder people aren't more supportive. Learning to do new things without>flinching will improve your paycheck.
In places where it would make sense to have a web server, we have web servers, use ssl, etc...  
chroots have there places, but using them solely to get around a given piece of software is not an ideal use of them.
Implementing a web server just to do a file transfer is an exercise in futility when the client will not use it.
Again, you keep trying to point me away from openssh.  Is there some reason you keep trying to persuade me to go away from openssh?   *(aside from nuisance factor)*
I regularly make use of new technologies, in many cases, just to learn something new.  However, not everyone shares that mind-set.  Trying to force change upon corporate clients, as it would be the clients who would have to learn to work with the new tools and change all of their automated routines to make use of them, would only end up causing more challenges than they solve.  It also has the problem of trying to work within corporate security, as it takes forever to get corporate clients and trading partners to change to different technologies.  So when a client says that they use scp, and nothing else, what choices do you have?   
>Also, you left out "use filesystem permissions, they're sexy and>drwx------."
 
I had stated that we already had permissions set appropriately.   I apologize for not re-stating the obvious again.>Sorry for wandering so far off topic. We now return you to your>regularly scheduled programming.
 
That's okay, I noticed that you seem to wander off topic regularly...
 
So - given that scp is the client software of choice, and that chroot is out due to the limits on implementations (scp-only only works within a user's home directory, and doesn't allow different directories to be used for different keys), I guess I have little choice but to look to the commercial ssh vendors who have already expressed an interest in the changes outlined.
 
Thanks again for your time.
 
_________________________________________________________________
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us