[Bug 225668] tcsh: reads /etc/hosts and calls name resolution erroneously to find REMOTEHOST

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225668

Jilles Tjoelker <jilles at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|New                         |Open
            Summary|'su' command reads          |tcsh: reads /etc/hosts and
                   |/etc/hosts and calls name   |calls name resolution
                   |resolution erroneously      |erroneously to find
                   |                            |REMOTEHOST
                 CC|                            |jilles at FreeBSD.org

--- Comment #1 from Jilles Tjoelker <jilles at FreeBSD.org> ---
Using ktrace -i on a su command, I found that it is not su, but csh that does
these strange DNS requests. The code tries to set the REMOTEHOST environment
variable and is in contrib/tcsh/tc.func.c getremotehost().

This exact problem is called out in a comment:

            /*
             * There is conflict with IPv6 address and X DISPLAY.  So,
             * we assume there is no IPv6 address in utmp and don't
             * touch here.
             */

However, the assumption is wrong. There can be IPv6 addresses in utmp(x).

A simple fix would be to use inet_pton() or getaddrinfo() with AI_NUMERICHOST
to check for an IPv6 (or also IPv4) address, and to skip the X DISPLAY handling
in that case.

This fix should be submitted to the upstream tcsh project first.

However, perhaps we want to eliminate more obsolete code here. The name of the
remote host is rather less important now for shell startup files than it used
to be when the code was written (such as to deal with terminal settings). It
may be sufficient to extract a hostname from the utmp host without touching DNS
at all.

Fortunately, there is a 2 second timeout on finding the remote hostname, so it
will not prevent you from logging in.

The "leaked" information is just the top 16 bits of the IPv6 address together
with the local DNS domain; perhaps the most important part is that you su'ed at
that time.

-- 
You are receiving this mail because:
You are the assignee for the bug.