resolver not working in a chroot

[Perry Hutchison]

Matthew Seaman <matthew at freebsd.org> wrote:
> On 20/01/2016 02:05, Perry Hutchison wrote:
> > There must be some difference in the lookup mechanisms between
> > the resolver and host(1), since host(1) works in the chroot.
>
> Yes.  host(1) uses only the DNS, whereas the general resolver functions
> can use all sorts of resolution mechanisms -- see nsswitch.conf(5).
>
> In order to track down exactly what the problem is I'd be running that
> ping command under truss(1) to try and spot what the failure is.  That's
> not guaranteed to work, nor is it generally completely obvious from the
> truss output what the trouble may be.  My guess though is that something
> is read-only which the system expects to be read-write.

That produced some interesting results, the first being that
truss(1) apparently does not like to run in a chroot:

  # chroot -u 0 -g 0 -G 105,0,5,20,25 /mnt truss -o \
    /var/tmp/ping-in-chroot ping -c 1 pkg.FreeBSD.org

produced 313 lines of

  -- CANNOT READ REGISTERS --

followed by process exit.

Having truss run the chroot showed that the resolver is correctly
deciding to consult the DNS after failing to find the hostname in
/etc/hosts -- /etc/nsswitch.conf specified "hosts: files dns" --
then falling over when it tries to open a socket for the purpose:

  open("/etc/hosts",0x100000,0666)                 = 4 (0x4)
  fstat(4,{ mode=-rw-r--r-- ,inode=12102,size=1090,blksize=8192 }) = 0 (0x0)
  read(4,"# $FreeBSD: releng/10.2/etc/host"...,8192) = 1090 (0x442)
  read(4,0x28820000,8192)                          = 0 (0x0)
  close(4)                                         = 0 (0x0)
  gettimeofday({1453281421.449818 },0x0)           = 0 (0x0)
  kqueue(0x0,0xbfbecccc,0x8,0x7273752f,0x62696c2f,0x28060aae) = 4 (0x4)
  socket(PF_INET,0x10000002,0)               ERR#43 'Protocol not supported'
  socket(PF_INET,0x10000002,0)               ERR#43 'Protocol not supported'
  socket(PF_INET,0x10000002,0)               ERR#43 'Protocol not supported'
  socket(PF_INET,0x10000002,0)               ERR#43 'Protocol not supported'
  socket(PF_INET,0x10000002,0)               ERR#43 'Protocol not supported'
  socket(PF_INET,0x10000002,0)               ERR#43 'Protocol not supported'
  close(4)                                         = 0 (0x0)
  madvise(0x28829000,0x10000,0x5,0x281eb468,0xbfbee138,0x28132e50) = 0 (0x0)
  madvise(0x28820000,0x2000,0x5,0x281eb468,0xbfbee138,0x28132e50) = 0 (0x0)
  madvise(0x28825000,0x1000,0x5,0x281eb468,0xbfbee138,0x28132e50) = 0 (0x0)
  write(2,"ping: ",6)                              = 6 (0x6)
  write(2,"cannot resolve pkg.FreeBSD.org: "...,56) = 56 (0x38)

In contrast, host(1) has no problem when run in the same way:

  socket(PF_INET,SOCK_DGRAM,17)                    = 3 (0x3)
  sendto(3,"\M^R>\^A\0\0\^A\0\0\0\0\0\0\^Cpk"...,33,0x0,{ AF_INET 192.168.0.1:53 },0x10) = 33 (0x21)
  select(4,{3},0x0,0x0,{5.000000 })                = 1 (0x1)
  fcntl(3,F_GETFL,)                                = 2 (0x2)
  fcntl(3,F_SETFL,O_NONBLOCK|0x2)                  = 0 (0x0)
  recvfrom(3,"\M^R>\M^A\M^@\0\^A\0\^A\0\0\0\0"...,65535,0x0,NULL,0x0) = 49 (0x31)
  madvise(0x28813000,0x10000,0x5,0x28399468,0xbfbfe3c0,0x282e0e50) = 0 (0x0)
  close(3)                                         = 0 (0x0)
  madvise(0x28810000,0x2000,0x5,0x28399468,0xbfbfe8c0,0x282e0e50) = 0 (0x0)
  gettimeofday({1453283485.628061 },0x0)           = 0 (0x0)
  madvise(0x28808000,0x1000,0x5,0x28399468,0xbfbfe948,0x282e0e50) = 0 (0x0)
  madvise(0x28808000,0x10000,0x5,0x28399468,0xbfbfe5d0,0x282e0e50) = 0 (0x0)
  fstat(1,{ mode=crw--w---- ,inode=192,size=0,blksize=4096 }) = 0 (0x0)
  ioctl(1,TIOCGETA,0xbfbfe768)                     = 0 (0x0)
  madvise(0x28809000,0x10000,0x5,0x28399468,0xbfbfe5d0,0x282e0e50) = 0 (0x0)
  write(1,"pkg.FreeBSD.org has address 96.4"...,40) = 40 (0x28)

The most glaring difference is that 0x10000002 second parameter
that the resolver passes to socket(2):  it should be SOCK_DGRAM (or,
conceivably, SOCK_STREAM -- if the resolver is using TCP instead of
UDP for its DNS queries).