DNS lookups inside a chroot

[Joshua Root]

I *think* this does that (corrections welcome...):

socat UNIX-LISTEN:mpchroot/private/var/run/mDNSResponder,mode=666,fork
UNIX-CONNECT:/private/var/run/mDNSResponder

But with that running, attempting to ping in the chroot just keeps
repeating these errors in system.log:
mDNSResponder[26]:  42: read_msg: ERROR failed to get errsd via SCM_RIGHTS
ping[99395]: dnssd_clientstub write_all(5) failed -1/28 32 Broken pipe

- Josh

On 2011-4-18 11:45 , Jeremy Huddleston wrote:
> Could you run a process outside of your chroot that will create a socket at /path/to/chroot/var/run/mDNSResponder as a proxy for /var/run/mDNSResponder?  I'm sure there are a ton of other similar issues lurking around, but that should at least work for communicating with mDNSResponder.
> 
> On Apr 17, 2011, at 14:25, Jordan K. Hubbard wrote:
> 
>>
>> On Apr 17, 2011, at 1:33 AM, Joshua Root wrote:
>>
>>> Maybe you can help me out then. :-) I can't get (lib)curl or ping to
>>> work inside a chroot (as created by MPAB) because their DNS lookups fail:
>>
>> I asked around and this is apparently a known issue with the chroot environment being unable to contact the mDNSResponder socket.  Untested, but what might work is running your own copy of mDNSResponder inside the chroot - copy the appropriate command line args out of the launchd plist for it.  This is one of those areas where chroot(1) is simply becoming more and more incompatible with Mac OS X (despite my earlier assertions that you should "just chroot") due to all the services that need to run.  A chroot environment does not have a launchd managing it, for example, yet something like that is what's really needed if you're going to run a shell in a chroot environment as if it were a fully-fledged instance of the system.
>>
>> Perhaps a better idea would be to enhance trace mode such that it "faults in" stuff on demand into a run-specific staging area.  Read-only opens of the files in the system would succeed, of course, it being only creations or rw/append opens which forced the copy, which means it wouldn't run all that slowly either.  What's the current behavior of trace mode across fork/exec boundaries?  Do the children get the properly interposed library such that they're also talking to the trace bits rather than the filesystem APIs directly?
>>
>> - Jordan