Re: DROP still returns -EPERM to userspace in OUTPUT chain

[Pablo Neira Ayuso <pablo@netfilter.org>]

Jan Engelhardt wrote:
> 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;
>      }

Hm, I see. Then I think that people should fix their applications instead.

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

But the DROP and REJECT behaviours refer to the packet logic, ie. with
DROP nothing is done, with REJECT we send some explicit packet (like an
ICMP administratively prohibited). That still applies to user-space.

Reporting -EPERM seems to me a good practise to report user-space
applications that the kernel is explicit dropping the packet. Otherwise,
while diagnosing problems, people cannot be sure where the packet has
been lost.

I'm more like in favour of forcing people to fix their applications,
they are doing a broken error handling.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html