On Sat, Mar 22, 2014 at 12:05 PM, Daniel Kahn Gillmor <dkg@xxxxxxxxxxxxxxxxx> wrote: > > You can check sysconf(_SC_ARG_MAX) to get an idea of the size limit. > > See: > > http://www.in-ulm.de/~mascheck/various/argmax/ > > for more detailed information. > > > > Also, setenv/putenv should return an error rather than overflow the > > buffer if the variable is too large. > > similarly, exec should fail with E2BIG if the data is too large. I ran some tests and it looks like setenv does not return an error when this happens but exec does (tested on Linux and Mac OS X). > So this is testable at runtime, when the peer sends a large key; in the > event that the variable is too large, AuthorizedKeysCommand would simply > fail closed. I think this is reasonable. Agreed. > We could also deliberately constrain the key size, and decline to > execute AuthorizedKeysCommand (or execute it without passing any key as > an environment variable or argument) if the client's proposed key is > larger than the largest key generated by ssh-keygen (16Kib at the > moment). This strikes me as a reasonable limit. If exec is catching the error for us then I don't see a need to impose another constraint on it that will have to be maintained. > Given the discussion, i'm still leaning toward either an environment > variable or argv. given that we're already using argv for the username, > i think a second argv parameter would be the cleanest. If compatibility with programs that expect exactly one command line parameter (the username) then it seems like the environment variable is the way to go. But I'll leave that decision up to those more involved with the development of openssh. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
