On Sun, Jun 1, 2014 at 3:10 AM, Graham Dumpleton <[email protected]> wrote:
> What I don't quite understand is why the Linux manual pages: > > http://man7.org/linux/man-pages/man7/unix.7.html > > are even promoting the style: > > offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1 > > That would produce a length with is technically 1 greater than what the > size of sockaddr_un can be. > If sun_path has non-\0 in every position, it can be even larger depending on where the first \0 is ;) But see below. > I can only imagine that within connect() it must be deducting 1 for any > possible null byte and so allowing the last byte of sun_path to be a non > null byte and never actually checking the last byte as specified by the > length, which would be beyond the valid length of the structure. > It is possible (or potentially required) to manage the sockaddr_un storage allocation yourself and support longer filesystem paths than will fit in the preallocated sun_path field. Exact limits vary by platform, but sun_path is generally declared smaller than the max supported path length. (See http://bugs.python.org/issue8882 for just one example discussion.) Thus the calculation of the sockaddr length based on actual data instead of the size of the structure, which may have to be mapped over a larger buffer in order to accommodate a more realistic path limit... (I think I alluded to this on the APR list. APR really isn't helping appropriately if it doesn't handle this ugly issue.) > In the Apache code for mod_proxy_fdpass at least it doesn't really matter, > as when copying into sun_path it ensures that the last byte that could ever > be written is the last one possible in sun_path and that will have a null > byte. So there is no risk the Apache code could overrun sun_path. > > I expect therefore that the Apache code could have simply used: > > sizeof(struct sockaddr_un) > > As for the original issue with mod_proxy_fdpass, that was plain wrong and > on some Linux systems could result in connect() failing with error: > > (22)Invalid argument > > as it would regard the supplied length as being over some internal limit > it checks. Doesn't happen on all Linux versions though based on what I have > had reported for some code of my own where I happened to replicate what > mod_proxy_fdpass was doing in that function. > > Graham > > > > On 1 June 2014 16:56, Christophe JAILLET <[email protected]> > wrote: > >> Fix in r1598946. >> >> CJ >> > > -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
