httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@apache.org>
Subject Re: Issue with connect() call made in mod_proxy_fdpass?
Date Sun, 01 Jun 2014 11:52:24 GMT
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 <trawick@gmail.com> wrote:

> On Sun, Jun 1, 2014 at 3:10 AM, Graham Dumpleton <grahamd@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.jaillet@wanadoo.fr>
>> wrote:
>>
>>> Fix in r1598946.
>>>
>>> CJ
>>>
>>
>>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
> http://edjective.org/
>
>

Mime
View raw message