Subject: Re: setrlimit seems to have changed: breaks pkgsrc/net/tor
To: YAMAMOTO Takashi <email@example.com>
From: Elad Efrat <elad@NetBSD.org>
Date: 01/12/2007 01:47:34
YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>>> YAMAMOTO Takashi wrote:
>>>>>> we use that argument to pass the
>>>>>> process requesting the rlimit change
>>>>> can it be different from curproc?
>>>> no. that's what the first version of the fix, as you can see.
>>>> however, keep in mind that the context may be forwarded to a userland
>>>> daemon or a different machine on the network for decision, so I don't
>>>> think we can rely on curproc/curlwp here...
>>> who decided to forward it can save the curproc by itself.
>> that's what I also thought initially, but I believe this will be
>> somewhat ugly: part of the context that is requested for decision
>> making will need to be "generated" by the secmodel code itself, rather
>> than just forwarded.
> "p = curproc" doesn't generate it.
>> are you absolutely insisting on not passing the requesting proc? :)
> no, as far as its usage is well-defined.
> (we have many functions which have proc/lwp pointer arguments with
> too vague semantics.)
I understand your meaning about "the requesting process" being always
curproc (technically, the currently executing process is doing the
request, yes :) but I still think that we should aim for full context
in the kpi and not "the 4 arguments + curproc for this action".
other than that, is it okay to commit?