prnames aren't encoded using xdr_string but as a vector of xdr_chars. As far as I can see there is no guarantee of NUL termination.
Using a vector of chars also means that strings take up 4x the necessary amount of space on the wire... S. Sent from my iPhone On 25 Jul 2012, at 18:41, Garrett Wollman <[email protected]> wrote: > <<On Wed, 25 Jul 2012 12:35:47 -0400, Jeffrey Altman > <[email protected]> said: > > [I wrote:] >>> Another strange inconsistency: these routines are very unclear about >>> whether they are dealing with strings or not. In places they are >>> careful to use interfaces like strncpy() that work on buffers, but >>> in other places they call string-only interfaces like stolower() that >>> will cheerfully walk off the end of the buffer. Is PR_MAXNAMELEN >>> supposed to account for a trailing null or not? (The RPC side of >>> things appears to believe the latter, although I haven't looked >>> closely enough to be certain.) > >> While the server does append a NUL at the end of the string, >> any network facing code should not assume that a string is NUL >> terminated. An evil server can choose to do otherwise. > > What the server does in this case does not matter, because XDR always > uses counted strings and does not send the NUL over the wire. Where > it does matter is what the client-side functions do with > maximum-length prnames. I'm trying clarify exactly what the XDR code > will do in this case, and also what the correct behavior in the client > library should be when given an argument that exceeds PR_MAXNAMELEN-1 > bytes: should it silently truncate or return an error? > > -GAWollman > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
