Re: Xtables2 Netlink spec

[Jesper Dangaard Brouer <hawk@diku.dk>]

Cc.ed Thomas Graf (tgraf@redhat.com), Thomas presented some interesting 
ideas on netlink error-codes and strings during NetConf 2010, see:

  http://vger.kernel.org/netconf2010.html
  http://vger.kernel.org/netconf2010_slides/tgraf_netconf10.odp


On Wed, 15 Dec 2010, Jozsef Kadlecsik wrote:
> On Wed, 15 Dec 2010, Jan Engelhardt wrote:
>> On Friday 2010-11-26 20:01, Jozsef Kadlecsik wrote:
>>> On Wed, 24 Nov 2010, Jan Engelhardt wrote:
>>>
>>>> By request of Pablo, I am posting the Xtables2 Netlink interface
>>>> specification for review. Additionally, further documentation and
>>>> toolchain around it is available through the temporary project page at
>>>>
>>>> 	http://jengelh.medozas.de/projects/xtables/
>>>>  * Runnable userspace library (libnetfilter_xtables)
>>>>    with small test-and-debug program
>>> [...]
>>>
>>> Please add fine-grained error reporting to the protocol: in my opinion the
>>> main shortcoming of the current kernel-userspace xtables protocol is the
>>> lack of the proper error reporting. I mean, the new protocol should be
>>> able to carry back which rule caused the error, in the rule whether it was
>>> a general kind of error (ENOMEM), or a table, chain, match or target error
>>> and exactly what was the error at table/chain/match/target level.
>>
>> That should not be a problem. However, what do we do with the general
>> kind of error that is overly general? A.k.a. the dreaded EINVAL.
>>
>> Say a user requested jumping to a chain, but did not give a chain name.
>> Normally that would be EINVAL, but EINVAL is overused already.
>
> When I wrote general error I meant the ones where there is no point (or
> cannot be) to specify the nature of the error exactly. Like in the
> example, ENOMEM: it's needles to report which new data field could not be
> allocated. But if the specified chain does not exists, that must not be
> masked by a general EINVAL. The user must be alerted that the chain with
> the given name does not exist.
>
>> What would you like? Comprehensive error numbers (sort of like the
>> ones Windows is said to use) aka. NFXTE_NO_CHAIN_NAME_GIVEN,
>> or a human-readable string; or something else?
>
> Yes, use comprehensive error codes. And it's the responsibility of the
> userspace tool to translate them to proper error messages.
>
>>> Say, the TCPMSS target should be able to report back that it cannot be
>>> used outside of FORWARD, OUTPUT and POSTROUTING.
>>
>> NFXTE_HOOKMASK_NOT_ADHERED or string?
>
> The former, i.e. error code.
>
>>> Or that the rule must match TCP SYN packets.
>>
>> TCPMSS doing a rule-search for -p tcp is pretty ugly (it must understand
>> the data structures, and that is sort of a backwards shot); Patrick
>> once suggested IIRC that TCPMSS should just silently skip non-SYNs.
>
> For the clarity of the rules I'd prefer the current solution, i.e. check
> and enforce that the rule matches TCP SYN packets. If we relax it, next
> time someone could complain why TCPMSS is restricted to FORWARD, OUTPUT,
> POSTROUTING, why can't the system simply skip the target when called at
> non-appropriate hooks.
>
> But I just picked TCPMSS target for errors which currently expressed
> in EINVAL.
>
>> Maybe both error numbers, and providing extensions with the
>> possibility to send strings? It is impossible to provision error
>> numbers for out-of-tree extensions, so having a way for an extension
>> to return some NFXTA_ERRSTR "One of my parameters is wrong!" seems
>> required at least.

I like this.

> I have got a three-level error coding in my mind: general, standard error
> codes (ENOMEM, EPERM, etc.), general netfilter specific ones (like
> NFXTE_HOOKMASK_NOT_ADHERED) and table/match/target specific ones.
>
> But I do realize that it's much easier (and therefore quite tempting) to
> construct the full error message in kernel space and just send it back.
> However, that'd make quite hard to support internationalization.

To support internationalization, we could just add an error-number-code 
in front of the constructed error message?

I'm a fan of the full error message system from the kernel, becuase its 
much easier to maintain, as we don't need to update iptables userspace 
each time we introduce a new error code/message.


Cheers,
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------