YAMAMOTO Takashi wrote:
>> 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".
> 
> are you going to change KAUTH_PROCESS_CANSIGNAL as well?
> 
> and how about other actions?
> assuming that you want to make the api itself independent from
> what bsd44 secmodel does, i'm afraid that you end up to add
> the proc pointer to all actions.

I was thinking the semantics of rlimit are specifically different,
because there were two different "authorization paths" for the two
cases (setrlimit(2) and sysctl proc.<pid>.rlimit).

I do understand your point here, though, and if you believe this
can become more than an isolated issue for this case, we can just
add a guideline that says "pass curproc too" for everything.

-e.