On Mon, Mar 24, 2014 at 12:23 PM, Peter Stuge <peter@xxxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
