[Bug 1269] using the internal lookup table vs. the local system's /etc/services (or so) generally prevents nft from working
bugzilla-daemon at netfilter.org
bugzilla-daemon at netfilter.org
Fri Jul 13 00:34:14 CEST 2018
https://bugzilla.netfilter.org/show_bug.cgi?id=1269
--- Comment #2 from D.Zaitceff <d at zaitceff.me> ---
(In reply to Pablo Neira Ayuso from comment #1)
> Probably better use variables for what you want? eg.
>
> define imap = 143
>
> tcp dport $imap ip daddr X.X.X.X counter dnat Y.Y.Y.Y
>
> So definitions are self-contained?
But it is not the correct side of the problem.
Nevertheless and by the way, look:
gentoo: grep imap /etc/services
imap 143/tcp imap2 # Internet Message Access
Protocol
imap 143/udp imap2
imap3 220/tcp # Interactive Mail Access
imap3 220/udp
imaps 993/tcp # imap4 protocol over TLS/SSL
imaps 993/udp
(Here I assume that Ubuntu is Debian-like)
debian: grep imap /etc/services
imap2 143/tcp imap # Interim Mail Access P 2 and 4
imaps 993/tcp # IMAP over SSL
So, IMAP is always here. But, in Gentoo it is the primary service name, while
in Debian IMAP2 is the primary one and IMAP is an alias. So, at first sight
the problem is the obviously incorrect implementation of the aforementioned
patch - alias names of the services are just forgotten. And so the IMAP name
is lost.
But this first sight is a short sight too. The real problem is not the
implementation, but the whole idea of the patch: to fake the system-level,
well-known and content-volatile database with a hard-coded snapshot of it. And
thus to lose the view of the reality - the actual list of the portnames -
forever...
It is like if one of the SHADOW project's authors decided to hardcode its
current /etc/passwd file into the sources... and just gave up using getpwent()
for the purpose.
/etc/services (or its NIS variant, or hesiod's one or whatever) is the
official, well known, stable, understood, simple, nice etc. database of
mappings between service names and port numbers. And _standard_ API is here.
To reinvent this weel is not just pointless, but also means to surely break the
way the system works.
--
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/20180712/b0d4d68b/attachment.html>
More information about the netfilter-buglog
mailing list