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

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

Jan Engelhardt wrote:
> Hi,
> 
> 
> 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? Returning
-EPERM seems to me quite sane to note that the kernel is explicit (via
iptables, for example) not allowing permission to send().

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