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/02/05 13:14:12 UTC
Proposed solution for bug #16056
(Please forgive the cross post, but I felt it relavent to the
httpd group, since it impacts them and module developers such as
myself.)
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 C Howe +33 6 11 89 73 78
http://www.snert.com/ ICQ: 7116561 AIM: Sir Wumpus
"Will the real email please stand up..."
Re: Proposed solution for bug #16056
Posted by Anthony Howe <ac...@snert.com>.
>> 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..."
Re: Proposed solution for bug #16056
Posted by Anthony Howe <ac...@snert.com>.
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..."
Re: Proposed solution for bug #16056
Posted by Anthony Howe <ac...@snert.com>.
>> 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..."
Re: Proposed solution for bug #16056
Posted by Anthony Howe <ac...@snert.com>.
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..."
Re: Proposed solution for bug #16056
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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
Re: Proposed solution for bug #16056
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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