cvs commit: src/sys/kern imgact_elf.c

Nate Eldredge nge at cs.hmc.edu
Tue Nov 15 10:12:55 GMT 2005


On Tue, 15 Nov 2005, Alexander Leidinger wrote:

> Olivier Houchard <cognet at FreeBSD.org> wrote:
>
>> cognet      2005-11-14 22:24:00 UTC
>>
>>  FreeBSD src repository
>>
>>  Modified files:
>>    sys/kern             imgact_elf.c
>>  Log:
>>  Add a new sysctl, kern.elf[32|64].can_exec_dyn. When set to 1, one can
>>  execute a ET_DYN binary (shared object).
>>  This does not make much sense, but some linux scripts expect to be able to
>>  execute /lib/ld-linux.so.2 (ldd comes to mind).
>>  The sysctl defaults to 0.
>>
>>  MFC after:      3 days
>
> Wait... wouldn't it be better to fix those scripts instead?

Well you can't really, that's inherently how things like ldd work on 
Linux.  I think it makes sense in a way: ld-linux.so.2 contains the code 
to resolve library dependencies, so if you want to know the dependencies 
you should ask that library.  The GNU/Linux folks choose to execute the 
library binary directly (which ELF allows you to do, it can have its own 
special main()) rather than communicate with it via magic environment 
variables or something.  This is arguably better because it can't 
interfere with environment variables that might be used for something 
else.

So you can't avoid that unless you change the way ld-linux.so works, or 
write a whole new ldd, and always make sure it searches in exactly the 
same way as the loader.  Neither of which is really in the spirit of 
emulation.

There are some other libraries on Linux which are executable, like 
libc.so.6, but it only prints out its version info and build options when 
run.

What I'm wondering is what's the point in making this a sysctl.  What 
benefit is there in turning it off?  If a library has this execution 
capability, why can't we just use it?

-- 
Nate Eldredge
nge at cs.hmc.edu


More information about the cvs-src mailing list