Re: APR-izing httpd's unixd_set_proc_mutex_perms

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Mladen Turk wrote:
> Long time since initial proposal, but here it is.
> Since there was no objections I'll commit this into trunk.

Does this API imply that the developer has to manage the resources
to be converted by uid/gid?

If so, I suspect you are ignoring others who the primary author is
unaware of.

The right API, IMHO, is to register a list of resources to be
converted *to whatever target uid/gid* will be used after fork.
Why should the author track these?

Re: APR-izing httpd's unixd_set_proc_mutex_perms

[Mladen Turk <mt...@apache.org>]

William A. Rowe, Jr. wrote:
>> Long time since initial proposal, but here it is.
>> Since there was no objections I'll commit this into trunk.
> 
> Does this API imply that the developer has to manage the resources
> to be converted by uid/gid?
> 
> If so, I suspect you are ignoring others who the primary author is
> unaware of.
> 
> The right API, IMHO, is to register a list of resources to be
> converted *to whatever target uid/gid* will be used after fork.
> Why should the author track these?
> 
>

Here is different API that allows registering the
perms_set callback to apr_procattr_t, eg.

  apr_procattr_perms_set_register(attr, APR_PERMS_SET_FN(shm),
	shm, APR_FPROT_UREAD | APR_FPROT_UWRITE | ...)

as well to call
the particular function independently from fork
eg.
APR_PERMS_SET_FN(shm)(shm, perms, uid, gid);

I suppose this can be extended to add settings for
file and dir as well, simply by implementing the
APR_PERMS_SET_IMPLEMENT(file)
APR_PERMS_SET_IMPLEMENT(dir)


Regards
-- 
^(TM)

Re: APR-izing httpd's unixd_set_proc_mutex_perms

[Mladen Turk <mt...@apache.org>]

William A. Rowe, Jr. wrote:
> 
> I'd actually want to allow such an API to target either uid, gid
> or both for apps who want to manage access by only one or the other,
> leaving access by uid or gid alone after fork.
> 

See the proposed one ...
(another attachment in this thread)

I've added additional include
(apr_perms_set.h) with API macros.

It allows to easily implement the
perms setter for any apr object
(where applicable of course)
and call it either directly or register
a callback to procattr that gets executed
using procattr uid/gid after fork


Regards
-- 
^(TM)

Re: APR-izing httpd's unixd_set_proc_mutex_perms

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Mladen Turk wrote:
> William A. Rowe, Jr. wrote:
>> Mladen Turk wrote:
>>> Long time since initial proposal, but here it is.
>>> Since there was no objections I'll commit this into trunk.
>>
>> Does this API imply that the developer has to manage the resources
>> to be converted by uid/gid?
>>
>> If so, I suspect you are ignoring others who the primary author is
>> unaware of.
>>
>> The right API, IMHO, is to register a list of resources to be
>> converted *to whatever target uid/gid* will be used after fork.
>> Why should the author track these?
>>
> 
> Make sense, but IMO as an additional API.
> We shouldn't make limit to set the object owners
> during fork only. A simple client server where
> server is running as root and client accessing its
> shared memory won't need to fork in all cases.
> 
> I presume you were thinking of list of callbacks
> that could be registered to apr_procattr_t and
> called after the fork is done, with its uid/gid.

Something like that, yea.  And you raise a good point w.r.t. some
deliberately shared resources.

I'd actually want to allow such an API to target either uid, gid
or both for apps who want to manage access by only one or the other,
leaving access by uid or gid alone after fork.

Re: APR-izing httpd's unixd_set_proc_mutex_perms

[Mladen Turk <mt...@apache.org>]

William A. Rowe, Jr. wrote:
> Mladen Turk wrote:
>> Long time since initial proposal, but here it is.
>> Since there was no objections I'll commit this into trunk.
> 
> Does this API imply that the developer has to manage the resources
> to be converted by uid/gid?
> 
> If so, I suspect you are ignoring others who the primary author is
> unaware of.
> 
> The right API, IMHO, is to register a list of resources to be
> converted *to whatever target uid/gid* will be used after fork.
> Why should the author track these?
>

Make sense, but IMO as an additional API.
We shouldn't make limit to set the object owners
during fork only. A simple client server where
server is running as root and client accessing its
shared memory won't need to fork in all cases.

I presume you were thinking of list of callbacks
that could be registered to apr_procattr_t and
called after the fork is done, with its uid/gid.


Regards
-- 
^(TM)