[OpenAFS-devel] ptuser interfaces: inconsistent downcasing

[Simon Wilkinson]

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 amo=
unt of space on the wire...

S.

Sent from my iPhone

On 25 Jul 2012, at 18:41, Garrett Wollman <wollman@csail.mit.edu> wrote:

> <<On Wed, 25 Jul 2012 12:35:47 -0400, Jeffrey Altman <jaltman@secure-endpo=
ints.com> said:
>=20
> [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.)
>=20
>> 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.
>=20
> 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?
>=20
> -GAWollman
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel