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. 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. 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 >
