You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Gregory (Grisha) Trubetskoy" <gr...@ispol.com> on 2003/08/19 17:04:38 UTC
[PATCH] mod_rewrite RewriteLock permissions fix
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.
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
+ }
#ifdef MOD_REWRITE_SET_MUTEX_PERMS
rc = unixd_set_global_mutex_perms(rewrite_mapr_lock_acquire);
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Gregory (Grisha) Trubetskoy wrote:
> Hmm... I think it went into MAIN as opposed to APACHE_2_0_BRANCH. It's not
> in 2.0.47, which still has the RewriteLock problem.
Right, but it is listed in the STATUS file on the APACHE_2_0_BRANCH
branch as something proposed for merging into APACHE_2_0_BRANCH.
JimJag had some comments there today that need to be properly addressed
though.
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Hmm... I think it went into MAIN as opposed to APACHE_2_0_BRANCH. It's not
in 2.0.47, which still has the RewriteLock problem.
Grisha
On Wed, 20 Aug 2003, Jeff Trawick wrote:
> I humbly submit that the patch already listed in
> APACHE_2_0_BRANCH/STATUS is what should be available in the next 2.0.x
> release:
>
> * Unix: Handle permissions settings for flock-based mutexes in
> unixd_set_global|proc_mutex_perms(). Allow the functions to
> be called for any type of mutex. PR 20312
> modules/mappers/mod_rewrite.c 1.153
> modules/ssl/mod_ssl.h 1.136
> modules/ssl/ssl_engine_config.c 1.81
> modules/ssl/ssl_engine_mutex.c 1.26
> os/unix/unixd.c 1.58
> os/unix/unixd.h 1.38
> +1: trawick, jerenkrantz
>
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
On Wed, 20 Aug 2003, Jeff Trawick wrote:
> The issues with your patch are:
>
> . your patch does the chown() for more than just flock()-ed files
>
> . there is a better place to put the non-portable flock() code, both to
> keep it out of mod_rewrite and to help solve the problem for any other
> modules
>
I agree - my patch was just a copycat from something similar done in
mod_ssl - I'm guessing the code i was copying from was probably removed by
the patch you mentioned.
Grisha
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by Jeff Trawick <tr...@attglobal.net>.
Gregory (Grisha) Trubetskoy wrote:
> 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.
hey, that's a pretty mean trick :)
> But this can be applied to 2.0, where I think it isn't fixed yet.
I humbly submit that the patch already listed in
APACHE_2_0_BRANCH/STATUS is what should be available in the next 2.0.x
release:
* Unix: Handle permissions settings for flock-based mutexes in
unixd_set_global|proc_mutex_perms(). Allow the functions to
be called for any type of mutex. PR 20312
modules/mappers/mod_rewrite.c 1.153
modules/ssl/mod_ssl.h 1.136
modules/ssl/ssl_engine_config.c 1.81
modules/ssl/ssl_engine_mutex.c 1.26
os/unix/unixd.c 1.58
os/unix/unixd.h 1.38
+1: trawick, jerenkrantz
The parts that fix mod_rewrite specifically are the changes to
mod_rewrite.c, unixd.c, and unixd.h. the ssl changes are just a cleanup
made possible by the infrastructure knowing when a chown() is necessary.
The issues with your patch are:
. your patch does the chown() for more than just flock()-ed files
. there is a better place to put the non-portable flock() code, both to
keep it out of mod_rewrite and to help solve the problem for any other
modules
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
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);
>
>
Re: [PATCH] mod_rewrite RewriteLock permissions fix
Posted by Jeff Trawick <tr...@attglobal.net>.
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);