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 <[email protected]> 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
>
