resolver not working in a chroot
Matthew Seaman
matthew at freebsd.org
Wed Jan 20 12:23:26 UTC 2016
On 01/20/16 11:07, Perry Hutchison wrote:
> 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).
Looks like ping(8) is OR-ing SOCK_CLOEXEC into the 2nd argument to
socket(2). That's perfectly fine according to the manual. The
'Protocol not supported' error you're seeing is not because of that.
Hmmm....
You've mounted a 10.2-RELEASE memstick image onto /mnt, but what OS
version is the parent host running? If you're trying to run a more
recent version of the OS in the chroot than in the host system, that
could well explain your experiences. The FreeBSD kernel is not
guaranteed to be forward compatible to software compiled on a more
recent version of the OS, although the reverse -- newer kernel and older
software -- will work.
Cheers,
Matthew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20160120/2c2e7857/attachment.sig>
More information about the freebsd-questions
mailing list