getent ahostsv4 seems to interact with network interface addressing

getent ahostsv4 seems to interact with network interface addressing

[Glenn Golden]

System:
  Arch linux, glibc 2.38-7, kernel 6.1.59-1, commodity i686 laptop.

Description of issue:
  Not sure if this is a bug or just a misunderstanding on my part as to how
  getent ought to be behaving when attempting lookups using the ahostsv4
  database, expecting it to query and return results from /etc/hosts.

  The behavior of "getent ahostsv4 HOSTNAME" seems to strangely depend on
  whether there are any network interfaces presently having an assigned v4
  address, as demonstrated in detail in "Steps to reproduce" below.

  In the typical case, when at least one network interface has a v4 address
  assigned to it, then "getent ahostsv4 HOSTNAME" behaves as expected, i.e.
  it returns the addresses of HOSTNAME obtained from /etc/hosts. But if there
  are no network interfaces having an assigned v4 address, then that same
  command fails with a null return and exits with code 2, which is documented
  (in getent.1) as

      "One or more supplied keys could not be found in the database."

  I am baffled by this. If this is expected behavior, can someone explain
  why?


Steps to reproduce (as root):

  #
  # Step 0: Display all interfaces having v4 addresses. NOTE: In this example,
  # interface wlu2 happens to be a WiFi dongle.
  #

      $ ip -4 -br addr
      lo               UNKNOWN        127.0.0.1/8
      wlu2             UP             192.168.1.16/32

  #
  # Step 1: Demonstrate that getent behaves as expected to resolve the v4
  # address of host 'sam.zplane.com' (which appears in /etc/hosts):
  #

      $ getent ahostsv4 sam.zplane.com
      192.168.1.15    STREAM sam.zplane.com
      192.168.1.15    DGRAM
      192.168.1.15    RAW

  #
  # Step 2: Now remove the v4 addr from interface wlu2:
  #

      $ ip addr del 192.168.1.16/32 dev wlu2

  #
  # Step 3: Confirm that wlu2 (or any other external interface) no longer
  # has a v4 address:
  #

      $ ip -4 -br addr
      lo               UNKNOWN        127.0.0.1/8

  #
  # Step 4: Now getent fails to resolve the same local host as before,
  # displaying nothing and exiting with code 2:
  #

      $ getent ahostsv4 sam.zplane.com
      $ echo $?
      2


  #
  # Step 5: Re-assign an address to wlu2. (NOTE: Any address will do here,
  # it does not have to be on the 192.168.1 local subnet.)
  #

      $ ip addr add 192.168.1.16/32 dev wlu2

  #
  # Step 6: Now getent once again behaves as expected:
  #

      $ getent ahostsv4 sam.zplane.com
      192.168.1.15    STREAM sam.zplane.com
      192.168.1.15    DGRAM
      192.168.1.15    RAW


Possibly related to:

    https://sourceware.org/bugzilla/show_bug.cgi?id=24816
    https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1945097
    https://unix.stackexchange.com/questions/98693/
    https://unix.stackexchange.com/questions/71379/


TIA for any insight into this behavior.

Thanks,

Glenn Golden

Re: getent ahostsv4 seems to interact with network interface addressing

[Florian Weimer]

* Glenn Golden:

> System:
>   Arch linux, glibc 2.38-7, kernel 6.1.59-1, commodity i686 laptop.
>
> Description of issue:
>   Not sure if this is a bug or just a misunderstanding on my part as to how
>   getent ought to be behaving when attempting lookups using the ahostsv4
>   database, expecting it to query and return results from /etc/hosts.
>
>   The behavior of "getent ahostsv4 HOSTNAME" seems to strangely depend on
>   whether there are any network interfaces presently having an assigned v4
>   address, as demonstrated in detail in "Steps to reproduce" below.

By default, getent uses AI_ADDRCONFIG under the covers, and what you
see is the expected behavior of that getaddrinfo option.  Recent glibc
versions have a getent option that switches of AI_ADDRCONFIG:

  -A, --no-addrconfig        do not filter out unsupported IPv4/IPv6 addresses
                             (with ahosts*)

Re: getent ahostsv4 seems to interact with network interface addressing

[Glenn Golden]

Florian Weimer <fw@deneb.enyo.de> [2023-11-05 21:10:50 +0100]:
> * Glenn Golden:
> 
> > System:
> >   Arch linux, glibc 2.38-7, kernel 6.1.59-1, commodity i686 laptop.
> >
> > Description of issue:
> >   Not sure if this is a bug or just a misunderstanding on my part as to how
> >   getent ought to be behaving when attempting lookups using the ahostsv4
> >   database, expecting it to query and return results from /etc/hosts.
> >
> >   The behavior of "getent ahostsv4 HOSTNAME" seems to strangely depend on
> >   whether there are any network interfaces presently having an assigned v4
> >   address, as demonstrated in detail in "Steps to reproduce" below.
> 
> By default, getent uses AI_ADDRCONFIG under the covers, and what you
> see is the expected behavior of that getaddrinfo option.  Recent glibc
> versions have a getent option that switches of AI_ADDRCONFIG:
> 
>   -A, --no-addrconfig        do not filter out unsupported IPv4/IPv6 addresses
>                              (with ahosts*)

Which getent.1 man page is the above excerpted from? It doesn't appear in 
the latest man-pages release (6.05.01-1 pkg on Arch) and it's also not
in the git man-pages tree at kernel.org:

  https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man1/getent.1

Am I looking in the wrong place for latest man pages?

Re: getent ahostsv4 seems to interact with network interface addressing

[Florian Weimer]

* Glenn Golden:

> Florian Weimer <fw@deneb.enyo.de> [2023-11-05 21:10:50 +0100]:
>> By default, getent uses AI_ADDRCONFIG under the covers, and what you
>> see is the expected behavior of that getaddrinfo option.  Recent glibc
>> versions have a getent option that switches of AI_ADDRCONFIG:
>> 
>>   -A, --no-addrconfig        do not filter out unsupported IPv4/IPv6 addresses
>>                              (with ahosts*)
>
> Which getent.1 man page is the above excerpted from? It doesn't appear in 
> the latest man-pages release (6.05.01-1 pkg on Arch) and it's also not
> in the git man-pages tree at kernel.org:
>
>   https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man1/getent.1
>
> Am I looking in the wrong place for latest man pages?

Sorry, it's just --help output.  I think we haven't updated the
manpages yet.