[Bug 1715] __netlink_gen_concat_key assertion raised by expanding set-defining variable as a component of a set key

[bugzilla-daemon at netfilter.org]

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

--- Comment #5 from kfm at plushkava.net ---
(In reply to Phil Sutter from comment #3)
> Just for the record: This is neither a crash nor "dying to a signal". It's
> merely an assert() call triggering because the parser constructed something
> the remaining code can't handle. Effectively this is a case of missing error
> handling (or insufficient parser strictness), not a bug.

Firstly, my ability to write and work with C is rather modest, so my
terminology might not be strictly correct. Still, if I run something in the
shell and see "Aborted (core dumped)" and can also see that the value of $? is
134, it hardly seems inaccurate to say that the process did, in fact, die as a
consequence of SIGABRT (134 - 126 being 6). Clearly, nft did not get the
opportunity to formally exit. So, if it did not die as a consequence of the
ABRT signal, how would you describe what happened?

I understand that the use of assert(3) is wilful and why you would take issue
with using "crash" as a term.

I do consider this as to be a genuine bug because I do not consider assert(3)
to be an appropriate means of conveying an error to the end-user, even if it be
unintentional. I wouldn't think this to be a contentious perspective. While the
assertion served a purpose - and is better than nothing - I am certain that the
end-user would prefer to see a formal diagnostic message, with nft having the
opportunity to exit with a non-zero status value. As such, I always report
assertions caused by the parser wherever I encounter them. I have reason to
believe that such reports are welcome as prior reports in this vein have been
attended to, for which I am grateful.

> 
> I guess the given ruleset works if you pull the second concat part into the
> defined variable like so:
> 
> define ext_if = { "eth0" . 22, "eth1" . 22 }
> [...]
>     iifname .tcp dport $ext_if accept
> [...]
> 
> right?

Yes, it does.

-- 
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/20231025/10c10801/attachment.html>