On Tue, May 14, 2002 at 09:06:44PM -0400, Roland McGrath wrote: > The file_exec call on the interpreter (sh) is where it goes from there. > That in turn results in an ordinary exec_exec of the interpreter file. > If you're unclear on what happens after that, read exec.c:do_exec, > S_exec_startup_get_info, and libc/hurd/hurdstartup.c.
Ah, the startup thing does it, I see now. > > However, I verified that the /dev/fd/3 mechanism works in a non-fakeroot > > environment. > > Hmm. Since it is getting the node to the underlying file in dtable[3], > there shouldn't be any difference from fakeroot in how accessing /dev/fd/3 > works (unless the /dev/fd magic isn't working right). Ha, that was way too easy with rpctrace. It turns out that /dev/fd/3 is looked up in the namespace of the fakeroot translator, which conveniently, but in a fundamentally broken way looks up the node and does all the MAGIC interpretation itself. So, the client gets to see whatever is fd 3 in fakeroot, which is invalid in this case. The same should apply to all other magic retries. The ultimate test was to set 3< /bin/bashbug in the fakeroot invocation, and see! All scripts that were broken before invoke bashbug from there on :) Now, this starts to look as if using file_name_lookup_under was not the best choice. Can't we use dir_lookup directly? Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
