Has there been any further discussion of this?
Anthony Howe
William A. Rowe, Jr. wrote:
At 06:14 AM 2/5/2003, Anthony Howe wrote:
Please find enclosed a proposed solution for the bug I posted last month:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16056
The source code comments in the patch should explain everything. I'm currently testing this against Apache 2.0.44 and the next release of mod_watch/4.1, which uses anonymous shared memory and mutexes.
Anthony, I like the gist of your patch, but your ownership observations were correct; we can't implement this patch as written. This was just addressed in recent Apache releases and will continue to be tightened, not loosened.
But I like the idea so much I believe we should do the same for mutex objects, and eliminate unixd_set_proc_mutex_perms() and unixd_set_global_mutex_perms() from the mainline code.
So how can we roll these into APR? That's a bitter question, since
we open up either the internals of APR or we end up narrowing the functionality to some defined subset.
I'm working up a list of 'objects' that might need permissions/uid/gid redefinition, if the process expects to setuid later. I'm working with that list of apr_foo_create() APIs to somehow pass the flag that we want this object under different ownership.
For the ownership questions (e.g. perms, uid, gid) I'm thinking of a transparent structure that gets stuffed into the object's pool userdata. A fallback option is to modify the apr_uid_get family to include some apr_uid_assuming_set that identifies the 'future' uid/gid to be toggled a little later.
Anyway, I was working with the mutex objects in Apache and all of the unixd_set_global_mutex_perms workarounds look just a bit
different, between rewrite, ssl, auth_digest and the core. I'd
like this code structure to be a whole lot cleaner, and nothing is
cleaner than dealing with the 80/20 inside of APR itself.
Bill
-- Anthony C Howe +33 6 11 89 73 78 http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus "Will the real email please stand up..."
