Created attachment 747 [details]
allow upload/download from fifo

This is one of those cases where the correct behaviour isn't immediately
obvious: I'm not sure that sftp should try to read from FIFOs.

In any case, please try the attached patch.

Actually, we can't apply this patch: it is impossible to tell if there is a
process on the other end of a fifo and reads will hang if there is none. We are
already hit by this bug in scp (see bug #856).

I strongly disagree. According to your logic nothing can legitimately read or
write a FIFO because it's every reader/writer's responsbility for the other end
of the pipe? You've just pronounced FIFOs unuseable by *anybody*?

In fact, I use Expect to drive sftp and I set my own criteria for timing out the
operation. Why is this a bad solution? If you're concerned someone will use a
FIFO without understanding what the ramifications are, why not default it to
non-support and allow users to pass a parm enabling the support?

Thanks,
Mark

WONTFIX - like I said, this causes too many problems.

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

Like I said, WONTFIX. If you want to transfer data to/from named pipes then you can use ssh with cat/dd/stdio redirection.

I'm sorry to reopen this bug report, but you have not addressed my concerns. The original bug (you refer to as the cause of disallowing named pipes) said SSH should not block on named pipes. The solution was to disallow named pipes. I am contending that this is an incorrect resolution for two reasons (which I wish you would address):

1) It breaks the unix concept of "everything is a file."

2) SSH's importance is its security. Using named pipes are beneficial in the most extreme implementations (such as in a DMZ) where writing the file to disk would be too much of an exposure. In those cases a forked process decrypts a file and serves it to the "getter" through a named pipe. (Or, reads a named pipe to encrypt data from the "putter.").

It's not that I disagree with the original bug report concerning how SSH blocks on FIFOs. It's that I disagree with how the problem was solved in such a sweeping manner. It should have been an option to SSH to skip FIFOs. 

In your last response you said I can use cat/dd/stdio redirection. I believe this will result in one of two things happening. It will either cause blocking (true FIFO behavior, which means the sweeping elimination of FIFOs didn't really fix anything). Or, it will allow data to be written to disk (because it's not blocked, but then eliminating the desired behavior described above in item #2).

If I have misunderstood how cat/dd/stdio would work, could you please give me a working example? I would be happy to evaluate it. If it is indeed a suitable solution perhaps you could add it to the FAQ? (The page for reporting bugs says to check the FAQ for things that aren't bugs at all. If this isn't a bug, then it seems like the FAQ should address this with an example of how SSH should be used with named pipes (to accomplish the goals outlined above). But, I'd like to review it before you publish it because, as I said above, I think it's either going to cause blocking (thereby calling into question the "fix" for #856), or allow data to be written to disk (which breaks the goal of eliminating data being written to disk).

I'm sorry to be a pest. I appreciate all the free work you do. I wouldn't continue to pursue this matter if I didn't feel it is serious.

Thanks,
Mark

Here is an example of using ssh to transfer to/from a FIFO:

ssh user@host "cat /path/to/yourfifo" > output
ssh user@host "cat > /path/to/yourfifo" < input

Naturally it is up to you to ensure that something is listening on the FIFO. If you have further questions, please ask them on a general ssh mailing list or newsgroup. A bug tracking system is not the place to field support questions.

Otherwise, you can use the patch that is attached to this bug to modify your sftp to do what you want.

As the original bug report stated, the problem is with sftp (and scp). We are not able to give shell access. Again, the issue is *security*. We use a named pipe so that data isn't written to disk. It stands to reason that we wouldn't grant shell access to such a system just as a workaround to what was an overly broad "fix" when someone asking for sftp/scp not to block. 

The solution should be to allow/disallow FIFOs via a command-line parm. Forcing everyone to never use them is not a solution. Forcing us to grant shell access (a greater security risk) is not a solution.

I think you need to face it. The fix for #856 was too sweeping. I don't mind patching SSH. But, that's not a long term solution. That's what I'm asking for.

Thank you for your time.

Mark

WONTFIX (as previously mentioned)

Mass update RESOLVED->CLOSED after release of openssh-5.1