[Bug 979] expr json structure

bugzilla-daemon at netfilter.org bugzilla-daemon at netfilter.org
Mon Jan 5 01:45:35 CET 2015


https://bugzilla.netfilter.org/show_bug.cgi?id=979

--- Comment #3 from Alvaro <alvaroneay at gmail.com> ---
(In reply to porjo38 from comment #0)
> The output of nft_rule_snprintf_json() includes a JSON array called 'expr'.
> I would like to suggest that each type be split into its own object where
> the 'type' value becomes the key name. So for example, rather than this:
> 
>   {
>     "type": "payload",
>     "dreg": 1,
>     "offset": 9,
>     "len": 1,
>     "base": "network"
>   },
>   {
>     "type": "cmp",
>     "sreg": 1,
>     "op": "eq",
>     "data_reg": {
>       "type": "value",
>       "len": 1,
>       "data0": "0x00000006"
>     }
>   }
> 
> Do this:
> 
>   {
>     "payload": {
>       "dreg": 1,
>       "offset": 9,
>       "len": 1,
>       "base": "network"
>     }
>   },
>   {
>     "cmp": {
>       "sreg": 1,
>       "op": "eq",
>       "data_reg": {
>         "type": "value",
>         "len": 1,
>         "data0": "0x00000006"
>       }
>     }
>   }
> 
> This will allow the json to be unmarshalled into separate data structures
> for each type of expr. I'm thinking of the case where libnftnl is wrapped by
> another language (Python, Go etc)

Good morning

In relation with the bug 979 of nftables: expr json structure

https://bugzilla.netfilter.org/show_bug.cgi?id=979

I'm going to explain why we use the actual json structure and the problem that
we can find with the json structure that you suggest.

The actual json output format is like you say:

{
    "type": "payload",
    "dreg": 1,
    "offset": 9,
    "len": 1,
    "base": "network"
  },

If you look the code in libnftnl, in the file src/jansson.c. You can find the
function "nft_jansson_expr_parse". With this function, we parse the expressions
in json.
We use a node like "type" because right now, we have a lot of different
expressions and in the future we want add more. Using the node type, we only
have to test and parse if this node exist and with the value we can create the
appropriate expr using the type. With this expr we can call to the parse
function associated to this expr.

If we use a structure like you propose:

{
    "payload": {
      "dreg": 1,
      "offset": 9,
      "len": 1,
      "base": "network"
    }
  },
  {
    "cmp": {
      "sreg": 1,
      "op": "eq",
      "data_reg": {
        "type": "value",
        "len": 1,
        "data0": "0x00000006"
      }
    }

With the json structure that you propose, we have to test if we have a node
called "payload", "cmp", etc. not only one "type".

First, we are going to have a very big function only to parse these nodes (Try
if we have a node called payload, if not cmp, if not ...). Because we have to
specify all kind of expressions that we have.

Second, if we want to add more expressions, we have to change every time the
functions to add the new rule expr to parse it in JSON format and XML format.

Thanks for the suggestion and I'm waiting your feedback to close this bug.

Alvaro Neira

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20150105/7b4e0434/attachment.html>


More information about the netfilter-buglog mailing list