netfilter buglog - Nov 2018 - [Bug 1301] New: Feature Request - "add set", "add element" - automatically import element members from a file

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

            Bug ID: 1301
           Summary: Feature Request - "add set", "add
element" -
                    automatically import element members from a file
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: james at nurealm.net

After working with "named sets", it would be convenient for nft to
learn to
automatically import the "elements" for a "named set" from
an external file,
when that list might be very long, as when, for instance, creating a drop rule
for addresses provided from ipdeny.com, rather than always needing to use a
subsequent command, as for instance "nft add element inet filter drop4 \{
$( tr
'\n' ',' < etc/zones.conf.d/cn-aggregated.zone ) \}", in
this example.

The format might look something like "set <set_name> { ...; element =
{
<file_path>, <element>, ... }", such that the contents of the
file are
pulled-in literally as the elements that would otherwise be written to
"elements = { <elements_list> }".  Presumably, nft can easily
distinguish a
file path, beginning with "/", from any other kind of element in a
named set.
Here, "<file_path>" may be used optionally as the first, or
only, element of
"<element_list>".  Perhaps it is just as easy to allow
"<file_path>" to be
placed anywhere in "<element_list>", then also allowing, for
instance,
"<file_path>, <file_path>, ... <element>, ..." .

Similarly, for "add/delete element { <element_list> }", the
format might simply
be "add/delete element { <file_path>, <element>, ... }".

Additionally, it would be convenient if nft would allow lists of elements in a
file to use alternate separators, such that <new_line> and <tab>
characters, in
addition to comma, are acceptable.  Lists are commonly provided using
separators other than comma, and it is convenient to not require conversion of
the file before use.

An incidental benefit of allowing nft to import long lists of elements directly
from external files is the opportunity to configure "flags constant",
which
perhaps allows some performance advantage, where "constant" cannot be
configured when "nft add element ..." is needed.

Another incidental benefit is the simplification of init configurations, which
invoke nft, which then no longer require additional multiple commands "nft
add
element ..." to be configured and executed subsequent to the initial
"nft -f
/etc/nftables.conf".  For example, no custom modification of the stock
"/usr/lib/systemd/system/nftables.service" would be required to invoke
the
additional commands.  In particular, systemd service units cannot directly read
file contents, and then something like a "sh" context must be invoked,
which
*does* allow file contents to be inserted into commands, as in the example
above.  This involves the further inconvenience of requiring additional proper
"escaping" syntax, as the command, as written, is interpreted, for
example,
first in systemd context, then in shell context, before finally in nft context.
 Proper "escaping" can be a very error prone process, where one wrong
character
can cause the entire command set to fail, often without a useful error message.

-- 
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/20181118/34c8999a/attachment.html>

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

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kfm at plushkava.net

-- 
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/20200128/8db7ad08/attachment.html>