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

Theodore Tso tytso at mit.edu
Tue Aug 22 04:42:03 PDT 2006


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?


Hmm....  I'm an old-school Unix compatibility veteran, which means I
never depend on the reverse port->service name mapping being useful
for anything other than display purposes, and if I use the the
service->port mapping for anything, the C code always had fallbacks in
case /etc/services didn't define the port for some reason.  Certainly
SuSv3 makes absolutely no promises regarding what getservbyname() or
getservbyport() will return, and any programs that tried accessing
/etc/services directly would be even less portable.

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.

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 (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....).

My proposal would be that we require LSB-certified applications to
have hard-coded fallbacks should getservbyname() or getservbyport()
return a failure, 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.

						- Ted




More information about the lsb-discuss mailing list