Phil Sutter <phil@xxxxxx> wrote: > > Something like: > > > > !attr_policy -> return -1; > > Which means I can't procrastinate writing the policies for all 40 > expressions. ;) Oh, right. > > type > nftnl_max_attr -> return -1: > > data_len > maxlen -> return -1. > > I wanted to make this an opt-in approach, so I'd rather go with > maxlen && maxlen < data_len -> return -1. Alright, it could be made more strict later once all have been converted. > > But I admit that this might break compatibility > > or otherwise leak internals into the api. > > It's not entirely straightforward, anyway. NFTNL_EXPR_IMM_CHAIN for > instance accepts literally anything as long as it's a NUL-terminated > string. I was unsure whether libnftnl should enforce > NFT_CHAIN_MAXNAMELEN there or not. Good point. ATM libnftnl and nftables are more tightly coupled, so I don't see why enforcing NFT_CHAIN_MAXNAMELEN would bite us at some point. We could also cap to 65528 which is what netlink would permit (nla attr header plus playload).
