> 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.

i still don't think it's a great idea to pass curproc everywhere
for aesthetic reasons.

given that it seems that the bug is annoying people,
how about postponing this discussion and fixing the problem using
curproc for now?  ie. a minimal fix.

YAMAMOTO Takashi