apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Proposed solution for bug #16056
Date Wed, 05 Feb 2003 20:10:10 GMT
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.


View raw message