apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: ftok (Was: Re: svn commit: r1561150 - /httpd/httpd/trunk/server/core.c)
Date Sat, 25 Jan 2014 00:54:27 GMT
OK... how about this:

 1. We fix the FIXME in unix/shm.c which sez that the
    shm permission should be 0600. We instead set
    it to 0644 ala the rest of the shared-mem permissions
    instead of the super-permissive perms we use now
    (for SysV shm). [1]
 2. We re-add the robustness fix for ftok to both 1.5-dev
    and 2.0.

Neither of these are, from what I can see, ABI
guarantees. We document these none-the-less so
people who *might* be affected have some info.

Comments?

1. #elif APR_USE_SHMEM_SHMGET
        new_m->realsize = reqsize;

        /* FIXME: APR_OS_DEFAULT is too permissive, switch to 600 I think. */
        status = apr_file_open(&file, filename, 
                               APR_FOPEN_WRITE | APR_FOPEN_CREATE | APR_FOPEN_EXCL,
                               APR_OS_DEFAULT, pool);


On Jan 24, 2014, at 6:51 PM, Branko ─îibej <brane@apache.org> wrote:

> On 25.01.2014 00:41, Jim Jagielski wrote:
>> Of course, one could also say that anyone who uses internal
>> APR implementation knowledge is doing something wrong...
>> 
>> And they would have a point.
>> 
>> But it still begs the question what to do w/ slotmem
>> which must set shmem permissions. I would guess what
>> we should really do is provide apr_shmem_perms(). We
>> could then have httpd 2.4 require APR 1.5.1 or later
>> and let those who choose to use ftok know the risks.
> 
> It would be APR 1.6, according to our API compat rules.
> 
> -- Brane
> 


Mime
View raw message