[Bug 943] sftp will not send from a named pipe

[bugzilla-daemon at mindrot.org]

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.