[lsb-discuss] potential lsb-apache FVT problem and /etc/services
bmark at us.ibm.com
Tue Aug 22 07:35:10 PDT 2006
Ted Ts'o wrote:
> On Tue, Aug 22, 2006 at 04:24:18AM -0600, Matt Taggart wrote:
> > So that lead me to wonder why Linux distributions' /etc/services
> > standardized. At the top of Debian's /etc/services there are the
> > comments,
> > # Updated from http://www.iana.org/assignments/port-numbers and other
> > # sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services
> > # New ports will be added on request if they have been officially
> > # by IANA and used in the real-world or are needed by a debian
> > # If you need a huge list of used numbers please install the nmap
> > The IANA source seems canonical, but it also lists commented
> > ports and also comments for contact info, those probably need to be
> > for a working copy. It also only lists officially assigned ports. Does
> > anyone know if IANA produces a more consumable version?
> > What are the conflicts in Linux distros?
> > Is it worth making them consistant?
> > What are the additions in Linux distros?
> > Are they large enough and consistant enough to warrant a "de facto
> > extension to the IANA list? Would there be value in such
["Amen" to the UNIX-veteran-ramblings, snipped]
> But of course, we don't know if future authors/maintainers of
> LSB-certified applications will be as careful, so maybe we need to say
> something. I'd be hesitant to duplicate the IANA's functions, and the
> IANA list does change as future ports are added, so simply saying that
> distributions must copy the IANA's list doesn't seem to a smart thing
> to do. So if were going to do anything we would have to snapshot the
> IANA list.
This is not recommended, from my "standards veteran" perspective.
Snapshotting the "current version" of a real-time canonical registry (be
IANA, ISO languages/locales, or FAA airport codes, whatever) instantly
makes you obsolete/incorrect and leads to multiple user interpretation
questions down the road. Always point to the definitive source (if you
can), don't copy it.
> In addition, even if we grabbed the IANA list, the IANA list does
> define both "http" and "www", and while it does list "http" first, as
> http 80/tcp
> http 80/udp
> www 80/tcp
> www 80/udp
> SuSv3 makes absolutely zero guarantees what getservbyport() will do if
> there are multiple entries like this. A valid implementation, given
> the IANA list installed in /etc/services, could return the first, the
> second, or none at all
Nope, it will *always* return the first entry that matches, as searched
from the beginning. The "www" entries will never be reached by
getservbyport(). They *will* be reached by getservbyname(www).
"The getservbyport( ) function shall search the database from the
beginning and find the first entry
for which the port specified by port matches the s_port member and the
protocol name specified
by proto matches the s_proto member, opening and closing a connection to
the database as
necessary. If proto is a null pointer, any value of the s_proto member
shall be matched. The port
argument shall be in network byte order."
getservbyname() has similar wording.
>(SuSv3 doesn't even guareantee that
> getservbyport() will reference /etc/services --- an valid
> implementation could be trying to do a YP query, and the Yellow Pages
> service could be down....).
That's true, we wanted to make sure that this would work in the future,
when this list might get long, or centrally controlled, or whatever.
> My proposal would be that we require LSB-certified applications to
> have hard-coded fallbacks should getservbyname() or getservbyport()
> return a failure,
This should be normal error-recovery, right? This is a quality-of-service
issue, not a standardization one.
> and to not depend on the output of getservbyport()
> for anything other than display purposes. We could make lsb_appchk
> flag warnings if an application uses either interface, and then
> require the certifier to answer a checklist stating that they are
> meeting these requirements for valid usage of the interface.
This is not necessary, IMHO, given my reading of getservbyname().
bmark at us.ibm.com
More information about the lsb-discuss