Date: Tue, 15 Nov 2005 02:12:53 -0800 (PST) From: Nate Eldredge <nge@cs.hmc.edu> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Olivier Houchard <cognet@freebsd.org>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern imgact_elf.c Message-ID: <Pine.GSO.4.63.0511150201070.2697@turing> In-Reply-To: <20051115103719.5c237st6o0gsckwg@netchild.homeip.net> References: <200511142224.jAEMO0RG057965@repoman.freebsd.org> <20051115103719.5c237st6o0gsckwg@netchild.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Nov 2005, Alexander Leidinger wrote: > Olivier Houchard <cognet@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@cs.hmc.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0511150201070.2697>