[Ecls-list] ECL build issues

[David A. Ventimiglia]

That all makes sense.  From a user's perspective, is it ok then just to
add /usr/local/lib (or whever the shared object file ends up) into the
LD_LIBRARY_PATH env variable?

Best,
David

On Mon, 2009-08-03 at 22:33 +0200, Waldek Hebisch wrote:
> 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).
> 
-- 
David A. Ventimiglia <ventimig at msu.edu>
Michigan State University