Hi Andrew, Ok, I reviewed the dlopen (Linux) and LoadLibrary (Windows) system calls for this area.
> 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. Ok, point taken. Also, if the broker is run as set-user-id, LD_LIBRARY_PATH is ignored. So other than setting an entry via ldconfig, you've little choice but to have a way to specify a directory, or set of them. Windows is quite another story... There are multiple schemes for searching, affected by registry security settings and dll-redirection files. Many of these things related to security get ignored if a full path is specified for the file to load. So doing things like forming full file paths out of user-provided paths tends to skirt the security settings. However, I learned some more reading MSDN this morning that we can use to add in search paths without disabling the security checks. So it's more workable than I knew before hand. > 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. Ok, I see your point. As long as we can avoid having to build full paths at run time, we should be ok on Windows. So the module-paths idea should work ok. Thanks, -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
