Nick Garlis <nickgarlis@xxxxxxxxx> wrote:
> Florian Westphal <fw@xxxxxxxxx> wrote:
> > Thats a userspace bug; userspace that makes use of NFT_CT_SRC/DST must
> > provide the dependency.
>
> Yes I guess that makes sense, garbage in, garbage out. I was just used
> to seeing some kind of errno being returned from any other invalid input
> and I assumed that it might have been a bug in the validation.
>
> > But why? As far as I can see nothing is broken.
>
> Honestly, I am not really sure whether it is an issue or not and this
> was mostly driven by the assumption that the kernel shouldn't trust the
> userspace to properly validate its input.
Its simply not possible to validate it in kernel.
Consider e.g. 'tcp dort 80'. nftables will insert the 'its tcp' check.
But userspace can also do
'meta l4proto { 6, 17, 132} th dport { 22, 23, 80}'.
The 'read 2 bytes from start of transport header' is the same.
So kernel cannot 'force' anything.
It will make sure that 2 bytes could be read from the given
offset. But it can't make sure that those bytes have a particular
meaning (port for instance).
> There is probably no strong enough reason to. Was the decision to not
> force dependencies intentional or something that was left as a TODO?
Its fully intentional, see above example.
> Thanks for taking the time to explain. Let me know if you'd like any
> more info about this or another patch involving nft_ctx instead.
> Otherwise, I’m fine leaving this here.
You could submit a patch for nftables userspace to no longer
emit NFT_CT_SRC/DST, I think there is no need to support kernels < 4.17
anymore.
