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