[Ecls-list] ECL build issues

[Waldek Hebisch]

David A. Ventimiglia wrote:
> 
> I built ECL 9.7.1 successfully on Ubuntu (Jaunty) on i386 platform, and
> make install seemed to work ok, but when I tried to run ecl I got this
> error:
> 
> ecl: error while loading shared libraries: libecl.so.9.7: cannot open
> shared object file: No such file or directory
> 
> Maybe my system's not set up correctly, but I don't typically get this
> sort of error when I build other applications from source.  It's not a
> huge deal, though, (I think) as I can run ecl after
> adding /usr/local/lib to my LD_LIBRARY_CONF environment variable in
> my .bashrc script.  But--assuming I haven't set up my system
> incorrectly--isn't this something that's typically handled by make
> install?
> 

Setting LD_LIBRARY_PATH used to be not necessary.  But some time
ago ECL was modified at request of security folks.  Namely, to
automatically find its shared library ECL used 'rpath' feature.
This feature is considered dangerous by security folks -- using
'rpath' means that ECL will search for its library in a set
of directories specified at build time.  If ECL binary is is later
installed on other machine it may happen that an adversary has
right to put files in one of places searched by ECL. Then using
apropriatly prepared 'libecl.so.x.y' the adversary can hijack
any ECL process.

I must say that IMHO not using rpath puts extra burden on users.
Possible solutions are:
-- limit rpath to configured directories (IIUC security folks
   consider such use OK)
-- use dlopen instead of rpath.  dlopen can be limited to configured
   directories and one can easily add additional checks (like checking
   that library is owned by correct user) so it may be more secure
   than rpath.  Also, dlopen is more flexible (but I one uses this
   flexibility there is potential for new security risks).

-- 
                              Waldek Hebisch
hebisch at math.uni.wroc.pl