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