patch to send incoming key to AuthorizedKeysCommand via stdin

[Scott Duckworth]

On Mon, Mar 24, 2014 at 12:23 PM, Peter Stuge <peter at stuge.se> wrote:
> ..it will no longer be writable. Does the last write() before buffers
> are full return short? If not, only write() a single byte at a time.
>
> I still do not see the problem here.

I've demonstrated how deadlock can occur in this situation at
https://gist.github.com/ScottDuckworth/9745307

When acting on a blocking file descriptor, a write() (or fprintf() in this
case) will block until either 1) all requested data is written or 2) there
is some sort of signal.  It will not "return short" if the pipe's buffer is
full, it will simply wait until it has free space in the buffer and repeat
until all data is written.

It would be possible to set the pipe to non-blocking mode so that the
fprintf() in key_write() will give up and return when the pipe's buffer is
full instead of blocking.  But in this case there is no way to distinguish
between when that pipe will not be read from and a pipe that is just being
read from slowly.  If it's just slow, we still would want to write the
entire key, and this would prevent that from happening.

Writing a single byte at a time would not help the situation.  In blocking
mode there will eventually be one byte that blocks, and in non-blocking
mode you'll still not know if the pipe is no longer being read from or if
it's just being read from slowly.

> A timeout within any general purpose OS is a heuristic, I don't think
> they belong in the authentication path.

I agree that a timeout does not belong here, but if communication were to
be done using pipes it would be the only way to avoid deadlock.  Hence the
reason why it's best to avoid using pipes for bi-directional communication
in this case.

> So maybe the new semantics deserve a new configuration option, rather
> than extending an existing option in a not-so-scalable way?

I agree with Daniel in that I don't see how the environment variable method
is not scalable enough for this scenario.