On Fri, Mar 21, 2014 at 12:50 PM, Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> wrote: > Are we sure this concern can't just be fixed in code? I don't > understand why using stdin would necessarily result in a deadlock to the > parent, but maybe i just haven't worked through the problem in enough depth. I haven't tried to produce the deadlock, but I think it's entirely possible when the incoming connection provides an extremely large public key (where the length of the base64 encoded keys is greater than the pipe size). The deadlock would be in key_write(), in the last call to fprintf() where the key type name and the base64 encoded key is printed to the FILE * that was passed to key_write(). It would deadlock because it's trying to write to a pipe that's never being read from. The pipe itself would buffer some unread data (how much varies by OS - I get 16KiB by default on Linux), and the FILE buffered I/O layer adds a little extra (I get a few hundred extra bytes on Linux/glibc). If the key size is greater than that then there's a deadlock. My first thought to fix this would be to put a timeout on this write, but that seems a little hackish and how that could best be accomplished is not immediately clear to me. I'm also now realizing that I haven't tested a AuthorizedKeysCommand that does close stdin, and I'm concerned that it would send a SIGPIPE to the writer and I'm not sure how that signal is handled in sshd. Maybe putting the write behind a select() or poll() could handle the timeout as well as detecting when the pipe is closed. After seeing all of this I am also in favor of environment variables. It seems like it would be cleaner and require fewer changes. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
