Ahh, I am partly being a goose. I kept reading that strlen() as sizeof() when reading the manual page. :-(
Graham On 1 June 2014 21:44, Jeff Trawick <traw...@gmail.com> wrote: > On Sun, Jun 1, 2014 at 3:10 AM, Graham Dumpleton <grah...@apache.org> > 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 <christophe.jail...@wanadoo.fr> >> wrote: >> >>> Fix in r1598946. >>> >>> CJ >>> >> >> > > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > http://edjective.org/ > >
