[lsb-discuss] potential lsb-apache FVT problem and /etc/services

Mark Brown 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 
weren't 
> > standardized. At the top of Debian's /etc/services there are the 
following 
> > 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 
assigned
> >  # by IANA and used in the real-world or are needed by a debian 
package.
> >  # If you need a huge list of used numbers please install the nmap 
package.
> > 
> > The IANA source seems canonical, but it also lists commented 
unassigned 
> > ports and also comments for contact info, those probably need to be 
removed 
> > 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 
ports" 
> > extension to the IANA list? Would there be value in such 
standardization?
> 

["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 
it
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
> follows:
> 
> 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().


-------------------
Mark Brown/Austin/IBM 
bmark at us.ibm.com




More information about the lsb-discuss mailing list