Re: Proposed solution for bug #16056

[Anthony Howe]

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16056

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.

Bugger.

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.

Yes. I thought this looks a little like a kludge.

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.

The APR is very nice when you consider what it accomplishes. I figured in order to handle target ownership & permissions, you either:

a) add three new parameters to apr_shm_create() for target owner and permissions; or

b) avoid the unix trick of deleting an open file handle/object in advance; then provide an apr_shm_set_owner() that sets ownership and permissions in a unix world and is a noop in other worlds. This would mean the shared memory release would be a cleanup handler. (Likewise for mutexes).

The second solution is what I implemented in mod_watch/3 for Apache 1.3 (see Shared.[ch] and Mutex.[ch]).

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()

My future port of mod_become would require this, since its sole purpose in life is setuid/gid or seteuid/gid the child process to that of the file-owner.

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