You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/08/20 17:06:56 UTC

Re: cvs commit: httpd-2.0 STATUS

jim@apache.org wrote:
> jim         2003/08/20 05:10:11
> 
>   Modified:    .        Tag: APACHE_2_0_BRANCH STATUS

>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/httpd-2.0/STATUS,v
>   retrieving revision 1.751.2.433
>   retrieving revision 1.751.2.434
>   diff -u -r1.751.2.433 -r1.751.2.434
>   --- STATUS	19 Aug 2003 16:06:20 -0000	1.751.2.433
>   +++ STATUS	20 Aug 2003 12:10:11 -0000	1.751.2.434
>   @@ -201,6 +201,14 @@
>            os/unix/unixd.c 1.58
>            os/unix/unixd.h 1.38
>            +1: trawick, jerenkrantz
>   +         0: jim (it seems to me that the locking mech itself
>   +                 should have the required flags to determine whether
>   +                 uid/gid and chown is required, rather than placing
>   +                 that knowledge in unixd.c (kind of what is done for
>   +                 the SSL stuff already with ChownMutexFile). Thus
>   +                 unixd would simply check those out and do what is
>   +                 required rather than having internal APR knowledge
>   +                 it shouldn't).

There is no longer ChownMutexFile in mod_ssl with this patch, the 
philosophy being that if APR doesn't know how to handle these 
platform-specific permissions issues, at least we can segregate it in 
unixd.c rather than having various modules have to think about it.

So where we are with this patch is that the platform-specific guts are 
split between unixd.c and APR...  APR tells unixd.c what mutex type it 
is, and unixd.c knows that flock needs the chown()...  modules don't 
need to know much, and it would better if they didn't even have to know 
not to call the function on Win32/OS2/whatever

What would be the interface if APR instead tells unixd.c that the lock 
file needs chown()?  Wouldn't that be adding an API to APR that we don't 
want long-term?  Also, is it an improvement for the chown() issue to be 
split in two places?

I don't see a big improvement until APR has some serious support for 
permissions/identity and unixd.c can say "hey, make sure this uid/gid 
can play with the mutex".