[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exec server and /dev/fd/N

From: Emilio Pozuelo Monfort
Subject: Re: exec server and /dev/fd/N
Date: Wed, 26 May 2010 12:29:06 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100515 Icedove/3.0.4


On 26/05/10 09:32, olafBuddenhagen@gmx.net wrote:
> On Mon, May 24, 2010 at 12:08:10PM +0200, Emilio Pozuelo Monfort wrote:
>> Basically the problem is that in some cases the exec server can't find
>> the file name of the file being executed (when it's a script), and
>> then makes a hack passing /dev/fd/N to the interpreter.
>> I tried to fix it with heuristics such as "if the file name contains
>> no slashes, then it's relative" and passing just a flag to the exec
>> server to avoid needing to create new RPCs, but that's not enough,
>> since a call like execv("foo",{"bar", NULL}) (i.e. filename !=
>> argv[0]) should work too. So the only option is to pass filename to
>> the exec server, and just use that.
> IIRC my major concern with this approach was that this way, the original
> task has to guess what file name will be valid in the new task's
> context... I don't remember though what my conclusion was regarding this
> being better or worse than doing the guessing in exec :-(

The point is that the original task doesn't need to do any guessing, since it
knows the file name. It's the one it's used to lookup the file_t. From all the
places that use _hurd_exec or file_exec, there's only one I haven't been able to
determine filename, and that's fexecve().

>> There's a little bootstrapping problem here: you can't apply the four
>> Hurd patches directly and build the whole Hurd, because lib*fs will be
>> using exec_exec_file_name, but the dynamic linker can't find it, since
>> libhurduser.so should provide it but you haven't build glibc yet. So
>> to bootstrap it (without hacks like partially building Hurd, e.g. what
>> we would need to do in the Debian packages) one would need to apply
>> all but 0004 patches to Hurd and build it, then build glibc with the
>> new Hurd installed, and then finally build Hurd with the 0004 patch.
> It's actually way easier than that: just copy the new .defs to
> /include/hurd before building the new glibc, which you can then use
> while building the new Hurd.

Sounds good for testing, but probably not a good idea for e.g. the Debian 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]