bugzilla-daemon at mindrot.org
2005-Nov-05 16:53 UTC
[Bug 943] sftp will not send from a named pipe
http://bugzilla.mindrot.org/show_bug.cgi?id=943 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX ------- Comment #4 from djm at mindrot.org 2005-11-06 03:53 ------- WONTFIX - like I said, this causes too many problems. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2005-Nov-05 18:25 UTC
[Bug 943] sftp will not send from a named pipe
http://bugzilla.mindrot.org/show_bug.cgi?id=943 mark.fuller at earthlink.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Comment #5 from mark.fuller at earthlink.net 2005-11-06 05:25 ------- Denying access to a valid file (a named pipe) seems like the incorrect way to handle people who may choose to use such a file (perhaps incorrectly). As far as I know, there are no other programs that handle named pipes this way. (FTP? Perl? Python? Other implementations of SSH?) The solution to using a named pipe is for the implementor to use a monitor of the process reading/writing the pipe. If someone on the other end doesn't want to access a named pipe, they should do an 'ls' and examine the output before acessing the file. You could add a flag to enable/disable support if you felt an 'ls' was too much work for the user. But, prohibiting access to a valid file is an usuaul, and I maintain incorrect way to handle it. This seems particularly incorrect in the case of SSH because SSH's noteriety is security. Using named pipes is the *only* way to securely run SSH on a box outside a firewall. Using a process to read a pipe (which SSH is writing to in the case of an external party performing a 'put') allows for encrypting data before it is written to disk. (Or, the same process in the other direction when a 'get' is involved and the pipe writer is decrypting the file on disk). This is obviously a very valuable use of named pipes as files. More valuable in this case than in a case using FTP (which doesn't prevent users from using pipes). It's the only way to ensure that no unencrypted data is written to disk. I'm sorry for being a pest. I appreciate the work you do. If there is a developer's list I can join and present my case for group discussion, I'd be happy to make my case and live with group consensus. Thank you, Mark ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
Seemingly Similar Threads
- [Bug 943] sftp will not send from a named pipe
- [Bug 943] sftp will not send from a named pipe
- [Bug 943] sftp will not send from a named pipe
- [Bug 943] sftp will not send from a named pipe
- [Bug 1120] sftp deletes files if destination==source and client==server