From dev-return-9135-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Wed Feb 05 20:08:29 2003 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 39734 invoked by uid 500); 5 Feb 2003 20:08:28 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 39690 invoked from network); 5 Feb 2003 20:08:28 -0000 Errors-To: Message-Id: <5.2.0.9.2.20030205083631.02e72ae8@pop3.rowe-clan.net> X-Sender: wrowe%rowe-clan.net@pop3.rowe-clan.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 05 Feb 2003 14:10:10 -0600 To: Anthony Howe From: "William A. Rowe, Jr." Subject: Re: Proposed solution for bug #16056 Cc: dev@httpd.apache.org, dev@apr.apache.org In-Reply-To: <3E410014.5030006@snert.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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