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