On Saturday 2009-05-23 12:47, Pablo Neira Ayuso wrote:
>>
>> once again, irc snatched this report:
>>
>> |2009-05-20T20:56 < Wintre:#Netfilter>
>> |
>> |Specifically, when I add a DROP rule to the local firewall, send(2)
>> |starts getting EPERM. The netfilter core code includes
>> |nf_hook_slow(), which says:
>> |
>> | /* Returns 1 if okfn() needs to be executed by the caller,
>> | * -EPERM for NF_DROP, 0 otherwise. */
>> |
>> |So, this seems kind of crazy to me. I always thought drop was
>> |supposed to be silent, and changing the return value of send(2),
>> |well. Bad. Anybody got a link to a discussion of this issue? Or is it
>> |just a plain old bug?
>>
>> I agree with the user here. For now, one had to make use of the
>> “STEAL” target [1] to get the real silent drop behavior for the
>> OUTPUT chain. Surely that is not the ideal thing either.
>> Requesting comments from NF maintainers.
>
>I'm curious, what application would need to ignore that error?
Well, the problem is that applications do not check for all
potential errors, just whether there was one or not:
while (there_is_data)
if (send(fd, &data[i], len) < 0) {
perror("the connection broke, or something we can't fix");
break;
}
Sure it feels a bit like the reliance on ext3 update intervals :-)
> Returning
>-EPERM seems to me quite sane to note that the kernel is explicit (via
>iptables, for example) not allowing permission to send().
Yeah but DROP is perceived by users to be "silently ignore it",
while the "you don't have permission" is REJECT's job.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
