Most likely it *is* fixed in 2.1 - I saw this problem on 2.0, but I looked
at the code of 2.1 and saw that the code looks the same, so assumed (I
know, assuming is bad...) that it is still broken. I haven't actually
tried verifying that it is a problem with 2.1 (it didn't occur to me to
look at unixd_set_global_mutex_perms() as in 2.0 IIRC it was something
SysV-specific).
But this can be applied to 2.0, where I think it isn't fixed yet.
P.S. My OS is FreeBSD 4.8 the preferred locking is flock() indeed.
Grisha
On Tue, 19 Aug 2003, Jeff Trawick wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
> > When the RewriteLock creates the global mutex on a system where file-based
> > locking is the default mechanism, the file is owned by root, and after
> > setuid/fork children will not have permissions to it. This should fix it.
>
> hmmm... some joker allegedly fixed this in 2.1-dev recently, yet you're
> apparently using 2.1-dev already based on the looks of your patch :(
>
> >
> > Grisha
> >
> > --- modules/mappers/mod_rewrite.c 19 Aug 2003 00:52:43 -0000 1.228
> > +++ modules/mappers/mod_rewrite.c 19 Aug 2003 14:55:32 -0000
> > @@ -2372,6 +2372,11 @@
> > "file %s", lockname);
> > return rc;
> > }
> > + else {
> > +#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
> > + chown(lockname, unixd_config.user_id, -1);
> > +#endif
>
> the unixd_set_global_mutex_perms() is supposed to do the chown() now
> when necessary... what is the mutex type for this mutex on your
> system, and can you check why unixd_set_proc_mutex_perms() isn't doing
> the chown() for you?
>
> (btw, the chown() is only needed when flock mutexes are used, as that is
> the implementation where the lock file has to be re-opened in the child
> process)
>
> > + }
> >
> > #ifdef MOD_REWRITE_SET_MUTEX_PERMS
> > rc = unixd_set_global_mutex_perms(rewrite_mapr_lock_acquire);
>
>
