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

[Mike Acar <mikeacar@gmail.com>]

I'd like to re-open this discussion. I apologize for not responding
sooner; I've been a bit busy. I'm also not subscribed to
netfilter-devel, so this message may bounce from there.

On Sat, May 23, 2009 at 6:20 AM, Jan Engelhardt<jengelh@medozas.de> wrote:

> Then again, people might be using -m limit -j DROP to simulate actual
> packet loss, for whatever scientific interests they currently have.

Which is precisely what happened: I was using DROP to simulate packet
loss to test timeout handling in a program. The program in question
does handle errors, but that wasn't the code path I wanted to
exercise. I wasn't aware of netem, but DROP would be all I needed in
this case (if it didn't return -EPERM).

In my former life as a sysadmin, it never occurred to me to interpret
DROP as "administratively prohibited"; that is what REJECT is for. I
interpreted DROP as "drop the packet silently, without any response",
which I think is the intuitive interpretation. An ICMP reply to a
remote machine is a response, and changing the return value of a
system call is also a response; neither is desirable.

The current behavior produces different results on local and remote
machines - programs on the remote machine time out, while programs on
the local machine get an error. I think this inconsistency - or
asymmetry - is undesirable.

What happens when adding an INPUT DROP rule for a protocol and port
bound for a socket where a daemon is listening? If we apply this
interpretation consistently, then when the rule is added, those
listen() calls should be interrupted and return -EPERM. I don't think
that's desirable behavior either - I think the kernel should drop the
packets when they arrive, and the listening daemon should never know
it happened.

Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> 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 don't agree. In fact, the current behavior makes this worse, because
the -EPERM behavior is unexpected (I think the interpretation of DROP
as silent is very common) and inconsistent (different things happen if
you're dropping remotely versus locally) - so it's not like you can
forget that you must check both end's firewalling rules when you're
diagnosing a problem.

-- Mike Acar