On Fri, 2009-11-06 at 16:18 -0500, Steve Huston wrote: > ... > A startup script can always set LD_LIBRARY_PATH.
It can't set a path without potentially affecting the shared libraries that the executable itself loads. So I don't think this is a viable solution. Setting LD_LIBRARY_PATH itself is generally recognised to be a security risk. What I'm suggesting is to keep the module load path and the ordinary shared library load path completely separate, which I think is really what we intend to do (at least on Unix like environments, even on Windows it seems like good idea). It seems to me to be completely sensible never to try to load module from the default LD_LIBRARY_PATH. ... > Also, trying to evade the OS policy is 1) confusing for people who > understand the policy, like sysadmins, and 2) a potential security > hole. I've done this before and would like to never go back. As above I think it's the reverse - setting LD_LIBRARY_PATH itself is the potential security issue. Andrew --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
