bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-inetutils] System files for services, protocols, and hosts.


From: Mats Erik Andersson
Subject: [bug-inetutils] System files for services, protocols, and hosts.
Date: Wed, 30 Nov 2011 21:45:51 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

(Forking into an independent and technical thread, to better
isolate this important material.)

onsdag den 30 november 2011 klockan 11:28 skrev Simon Josefsson detta:
> Mats Erik Andersson <address@hidden> writes:
> 
> > onsdag den 30 november 2011 klockan 10:44 skrev Simon Josefsson detta:
> >> 
> >> Where does InetUtils require a /etc/services?
> >
> > The library call getservbyname(3) does so, and we are using it!
> 
> POSIX allows that the function to be implemented without /etc/services.
> 
> Is there anywhere in InetUtils we use getservbyname without checking
> that it returns NULL?  That would be a bug worth fixing.

There are cases where its failure to answer properly will produce a sane
replacement value, and there are cases which reports a lookup error, and
there are cases which abort execution.

> Is there any other reason we require a /etc/services file?

I would extend this to:

  Do we still depend on any of the files

     /etc/services
     /etc/protocols    ("tcp" and "udp")
     /etc/hosts        ("localhost")

  without coding a proper recovery?

A code audit for this matter could be viewed as a milestone for our
next iteration.

Giuseppe Scrivano recently mended a dependency on "/etc/hosts" via
"localhost" for our test script "tests/syslogd.sh".

Critical code would a priori occur with getservbyname(3), getaddrinfo(3),
getnameinfo(3), unless improved versions are available in Gnulib.

The method of providing safe defaults would be to state numerical strings
as fallback value, i.e., "514" instead of "syslog". Regrettably I have
failed myself to follow this recipe when replacing getservbyname() by
getaddrinfo() in "src/syslogd.c". Thus I now know there is room for a
thorough auditing in this most interesting area.

Regards,
  Mats



reply via email to

[Prev in Thread] Current Thread [Next in Thread]