Date: Wed, 20 Jan 2016 03:07:30 -0800 From: perryh@pluto.rain.com (Perry Hutchison) To: freebsd-questions@freebsd.org Subject: Re: resolver not working in a chroot Message-ID: <569f6a72.IDjZt6e6TrIMfmrk%perryh@pluto.rain.com> In-Reply-To: <569F44DB.4080406@FreeBSD.org> References: <569e05b6.2RStkLc7SZIg/dVM%perryh@pluto.rain.com> <569E12B2.5090302@freebsd.org> <569eeb77.GFz8dwXgj3CL44SN%perryh@pluto.rain.com> <569F44DB.4080406@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Seaman <matthew@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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?569f6a72.IDjZt6e6TrIMfmrk%perryh>