You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Anthony Howe <ac...@snert.com> on 2003/03/01 13:24:16 UTC

Re: Proposed solution for bug #16056

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