Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <498729D5.1080004@rowe-clan.net>
Date: Mon, 02 Feb 2009 11:13:57 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: Mladen Turk <mturk@apache.org>
CC: APR Developer List <dev@apr.apache.org>
Subject: Re: APR-izing httpd's unixd_set_proc_mutex_perms
References: <488177E4.1090802@apache.org> <49848387.6040705@apache.org>
 <4985DC6C.9030305@rowe-clan.net> <4986A0F5.5050301@apache.org>
In-Reply-To: <4986A0F5.5050301@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.