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".
