Re: CVS commit: src/bin/hostname

["Roland C. Dowdeswell" <elric%imrryr.org@localhost>]

  [-source-changes-d%NetBSD.org@localhost, +tech-userlevel%NetBSD.org@localhost]

To summarise the thread so far: I am replying to a set of changes to
hostname(1):

On Wed, Jul 24, 2013 at 08:47:44PM +1200, Alan Barrett wrote:
>

> On Fri, 19 Jul 2013, Erik Fair wrote:
> >>Modified Files:
> >>    src/bin/hostname: hostname.1 hostname.c
> >>
> >>Log Message:
> >>Add the following options
> >>-A Display the FQDN of each address on all interfaces.
> >>-a Display alias name(s) of the host.
> >>-d Display the DNS domain.
> >>-f Display the FQDN for the hostname.
> >>-I Display each IP address on all interfaces.
> >>-i Display the IP address(es) for the hostname.
> >Not to go all Rob Pike on you (cf. "cat -v considered harmful"),
> >but what the heck is all this for?
> 
> And also: Where was this change discussed?

I don't recall a discussion but it's quite likely that I missed it,
but just in case, maybe tech-userlevel@ is the correct venue for it.

I think that we need to be careful about these changes for a number
of reasons.  Rather than complain about how many options hostname(1)
has just grown, I have some concerns about the specific features,
how useful they are, how they are implemented, how they are
documented, and how they might guide user behaviour in the future.

I can accept the argument that it might be beneficial to have a
set of switches corresponding to Linux's which is what I believe
that this patch is intended to provide, however, I think that the
Linux hostname(1) is fundamentally misguided in a number of ways.

Their documentation states ``/etc/hostname  This file should only
contain the hostname and not the full FQDN.''  This is counter to
the guidance that we give our users in the NetBSD Guide and this
decision on their part very much drives how they decided to implement
their hostname(1) changes.

The main issue that I see is the use of reverse resolution:

In order to determine a host's ``full FQDN'', Linux's hostname(1)
will perform a forward and reverse name lookup on the value retrieved
via gethostname(2).  There are numerous issues with this.  First,
name service is insecure.  Sure, the user _can_ make the appropriate
settings in /etc/hosts to ensure that the data is collected locally
but there is no guarantee that will be the case, there are no errors
if that is not the case.  In short, in many or even most environments
hostname -f will provide insecure information.

It is very easy to end up with something like this:

        $ ./obj/hostname
        roofdrak.imrryr.org
        $ ./obj/hostname -f
        cpe-1-2-3-4.rr.net

It is not generally a good idea to presume that people will control
their reverse resolution because it is delegated differently to
forward resolution.  Even at medium to large enterprises, it is
often the case that those that control the reverse resolution are
different to those that control the forward for very obvious reasons:
they are allocated using a different model.

Second, it may rely on a network connexion:

        $ ./obj/hostname -f
        hostname: getaddrinfo: No address associated with hostname

is what I'm getting right now because I turned networking off.
Given that my host, following NetBSD guidance, has its FQDN configured
via sethostname(2) in the kernel, it is a little odd that if I ask
for it, I receive an error.

Needless to say, a host's name may very well have security implications
as applications tend to trust it.

Now, we need to remember that many start scripts and the like which
have been written for Linux are likely to use hostname -f (or maybe
hostname --fully-qualified-domain-name) and our implementation may
therefore affect the behaviour of applications that are installed.

The -i switch has similar problems in that it reports an IP address
generated from getaddrinfo(3) rather than querying any interface.

The -d switch is documented incorrectly as ``Display the DNS domain''.
It should probably read something like ``Display everything after the
first dot of the hostname.''  We should neither presume that DNS is in
use nor incorrectly use the terminology: a hostname is a DNS domain as is
everything after the first dot or everything after the last dot.

The -a switch is documented as deprecated in Linux.  Perhaps we shouldn't
implement it.

The -f switch is incorrectly documented.  The concept of an FQDN is not
really properly defined.  If anything, it should be documented to return
the forward and reverse lookup of the hostname via the NSS framework.  That
said, I'd rather change its behaviour to simply return the hostname.

We should also note that these flags are provided for Linux compatibility
and their use is discouraged.  It might also be a good idea to document
that we expect the hostname to be an FQDN.  I'd probably propose that we
also indicate that hostnames are not really divisible and that parts of
a hostname don't really have much semantic meaning to a computer but
really only have semantic meaning to humans.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/