Re: CVS commit: src/sys/netinet6

[Elad Efrat <elad%NetBSD.org@localhost>]

On Sun, May 10, 2009 at 8:44 AM, YAMAMOTO Takashi
<yamt%mwd.biglobe.ne.jp@localhost> wrote:

>>> have you checked callers and ensure that the change from EACCES to EPERM
>>> won't be a problem?
>>
>> Only ipsec_set_policy() returns EPERM instead of EACCES now, and I
>> don't think it should be a problem.
>
> "don't think"?  why not?
> i asked if you checked what the callers of ipsec_set_policy do with
> the error number.  do you mean "yes, of course"?
>
>> As for calling context -- I did look at the callers and mostly I just
>> moved the call inside instead of at the top. That's also why I didn't
>> remove the last one in in6.c, where is obvious that it's done before
>> splnet(), and still need to take care of it. :)
>
> i'm not sure what you mean.
> my question was about the ipsec.c change.  sorry if it was not clear.
>
>> It's possible though that I've missed something. Do you see any problems?
>
> i don't know if there are problems or not.
> i'm not familiar with the code in question.
> i was just wondering about the implications of the error number change.

Okay, I misunderstood you. I thought you were asking about the calling
context *and* the error value.

Anyway, the error value is just returned. The caller returns it if
it's not zero. I could not find a place that checks specifically for
EACCES, or documentation that says the user should check for it.
Ioctl(4) doesn't mention it at all.

That said, where we now return EPERM is where in the future we'll
return the error value returned by kauth(9), like many many other
places in the kernel. Other parts of the networking stacks (say,
opening a raw socket) now return EPERM instead of EACCES -- if we're
interested in checking whether this is a problem or not we should do
so on a much larger scale, and not as a response to a specific change.

Thanks,

-e.