In article <[EMAIL PROTECTED]>,
Harald Welte <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 14, 2002 at 01:02:32AM -0400, Zygo Blaxell wrote:
>> I wonder if there has been some thought to what happens to e.g. a GUI
>> config tool when new options to an iptables module are added. Will there
>> be a backward-compatible mechanism that can be used if the GUI finds
>> a data type newer than itself?
>
>The GUI can query libiptables about available plugins and their options.
>Everything behind is covered by libiptables. The Applications _must not_
>make any assumption on which options are present and what data types
>they use. Everything needs to be read via libiptables at runtime.
This sounds contrary to the stated goal. GUIs and machine rule
generators have to make assumptions about at least some subset of the
options they are prepared to use; otherwise, they are simply fancy text
editors and syntax checkers specialized for writing iptables scripts
or input for iptables-restore, but with no ability to do anything other
than data format translation between two entities that already know
everything they need to know about each other except for the protocol
they use to communicate.
A sophisticated GUI usually wants to present different data types
differently, e.g. one widget for an IPv4 address, one for a host name or
IPv4 address, one for IPv4/netmask, IPv4/maskbits, netmask, etc; however,
these are all four-octet (or 8-octet for addr/mask) tuples. Machine rule
generators want to take an abstract specification (e.g. "let people
access my web server") and convert it into a concrete implementation
("allow some ports, block other ports, etc."). Neither can be usefully
done without making some assumptions about options or data types, and
actually a lot of assumptions about the overall netfilter architecture
(e.g. "where can I put an egress policing rule?"). An extension might
supply some semantic hints separately from the data type, which suggest
which of many possible assumptions might apply, but there's no way to
remove the assumptions without making the tools utterly trivial.
The problem I see here is that new data types might be required for
new extensions in the future (e.g. we start with int/bool/IP
address/netmask, etc, and later add time intervals and binary strings).
The iptables command-line utility handles this by declaring all option
fields to be lists of strings (by convention these are [!]option+argument
pairs), and then the extensions internally convert these strings into
other types using their own possibly completely arbitrary rules.
New data types are trivially supported by the existing iptables since at
the highest interface level they are all lists-of-strings, so any GUI or
machine rule generator only needs to be able to transport lists-of-strings
between a user and the iptables extensions, and only needs to know how
many strings to transport. If such tools could understand the semantics of
the strings, they may also e.g. look up hostnames, display bitmasks in
hex but other ints in decimal, and so on; however, if the tool doesn't
understand the semantic meaning of the strings, then it can just use the
strings themselves and it would still be useful.
What I get from reading about iptables2 is that this extensibility will
be lost--if a tool does not understand a parameter type, it will be
unable to supply that parameter (except perhaps as a hex-encoded binary
string, assuming it can figure out the size somehow). The README file
in the iptables2/libiptables directory suggests that the generality we
presently enjoy will go away, to be replaced by 11 or 12 slightly more
specific parameter types. If this happens, in the future I predict one of
two outcomes: 1) the list of specific data types grows to an extent
and at such a rate that no frontend can ever implement all of it,
2) most of the parameter types that don't fit into the first 11 or
12 supported cases will use a catch-all "text string" parameter type
(which interestingly enough is not one of the initially proposed 11
or 12 specific things in iptables2/libiptables/README) and parse the
parameter in the extension library.
>With libiptables (as soon as it is fully implemented) it is possible to
>write a GUI (or any other application) which doesn't know anything about
>individual matches/targets, their options, data types or help messges.
>The application does not need to be modified if a new match/target is
>written.
I agree it's possible, but IMHO it's no more useful than an automated
syntax checker and an online help browser.
>Please see the README file, it gives some basic idea...
It doesn't answer very many questions. ;-)
--
Zygo Blaxell (Laptop) <[EMAIL PROTECTED]>
GPG = D13D 6651 F446 9787 600B AD1E CCF3 6F93 2823 44AD
