See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest.
Thoughts/suggestions?
2011/8/23 Orion Poplawski orion@cora.nwra.com:
See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest.
Thoughts/suggestions?
Would something like this work?
module () { eval `/lib64/ld-linux-x86-64.so.2 --library-path '' /usr/bin/modulecmd bash $*` }
(on a 64bit system; on a 32bit system it would need to use /lib/ld-linux.so.2).
- Thomas
On 08/23/2011 12:47 PM, Thomas Moschny wrote:
2011/8/23 Orion Poplawskiorion@cora.nwra.com:
See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest.
Thoughts/suggestions?
Would something like this work?
module () { eval `/lib64/ld-linux-x86-64.so.2 --library-path '' /usr/bin/modulecmd bash $*` }
(on a 64bit system; on a 32bit system it would need to use /lib/ld-linux.so.2).
- Thomas
Hmm, I like this idea. I think it would protect the default system, but still allow for end users to override it for some reason. It might even be acceptable upstream.
I'm CC'ing the packaging list to get their thoughts.
On 08/23/2011 11:44 AM, Orion Poplawski wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest.
Thoughts/suggestions?
IMNSHO disabling LD_LIBRARY_PATH is a bad thing. A user may need it for some reason that you don't anticipate. If someone uses LD_LIBRARY_PATH, it is up to them to make sure that they don't force incompatible libraries to be loaded. If they report bugs against Fedora packages (including the environment module system) due to library incompatibilities when using LD_LIBRARY_PATH, I think the correct response is to tell them not to do that, and that it is not a bug in the package.
Generally the correct thing to do if an application is incompatible with the system-supplied Tcl is to rebuild that application. Granted, that's not possible with closed-source software like the Xilinx ISE referenced in that bug. However, I don't see it as a job of Fedora to fix problems in proprietary software.
As it happens, I actually use Xilinx ISE myself, and while I hadn't tried it with the environment module system, if I did do that and had trouble with it, and you told me that it wasn't supported, I would simply use it without the environment module system.
Eric
On Tue, Aug 23, 2011 at 11:44, Orion Poplawski orion@cora.nwra.com wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=719785 for the motivation
The environment module system allows users to modify their environment in a predictable way, including setting LD_LIBRARY_PATH. However, this makes it possible to break the modulecmd binary by putting an incompatible TCL (or other) library earlier in the path. It would be great if modulecmd were made impervious to such things, but I don't know the best or acceptable method to do this. I'm guessing using rpaths would be the easiest.
Thoughts/suggestions?
To be honest, I think this falls under: User shoots self in foot. I have run into this a lot and done it quite a few times myself... but in the end it usually meant finding out I had old software I no longer needed while not breaking software I still needed to have work. Is this a security issue?