[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:1.9.1.9) Gecko/20100515 Icedove/3.0.4 |
Hi,
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
packages.
Emilio
- [PATCH] Use the new __hurd_exec_file_name RPC, (continued)
- [PATCH 3/3] Use the new _hurd_exec_file_name function, Emilio Pozuelo Monfort, 2010/05/27
- Re: [PATCH 3/3] Use the new _hurd_exec_file_name function, Carl Fredrik Hammar, 2010/05/31
- [PATCH 2/3] Add a file_exec_file_name RPC, Emilio Pozuelo Monfort, 2010/05/27
- Re: [PATCH 2/3] Add a file_exec_file_name RPC, Carl Fredrik Hammar, 2010/05/31
- Re: exec server and /dev/fd/N, Carl Fredrik Hammar, 2010/05/31
- Re: exec server and /dev/fd/N, Carl Fredrik Hammar, 2010/05/31
Re: exec server and /dev/fd/N, olafBuddenhagen, 2010/05/26