Shared lib template broken under linux ???

**fullmetalcoder** · 25th April 2006, 20:03

Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!!

Is there a way to do that programmatically because I don't wanna force each user of my app to do that stupid trick on its own... I think there some QApplication static functions that deals with library paths but will they work from the application itself or will loading fail before the static function is called???

**krawek** · 25th April 2006, 20:22

Originally Posted by fullmetalcoder

Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!!

Is there a way to do that programmatically because I don't wanna force each user of my app to do that stupid trick on its own... I think there some QApplication static functions that deals with library paths but will they work from the application itself or will loading fail before the static function is called???

Predefined library path avoid security problems, for launch application write a simple script:

Qt Code:

Switch view

#!/bin/bash
export DEVQT_HOME=/path/to/data/files/
export LD_LIBRARY_PATH=${DEVQT_HOME}/lib
 
#and launch app
${DEVQT_HOME}/bin/devqt

#!/bin/bash
export DEVQT_HOME=/path/to/data/files/
export LD_LIBRARY_PATH=${DEVQT_HOME}/lib

#and launch app
${DEVQT_HOME}/bin/devqt

To copy to clipboard, switch view to plain text mode

in MacOsX LD_LIBRARY_PATH is DYLD_LIBRARY_PATH

**wysota** · 25th April 2006, 21:13

Originally Posted by fullmetalcoder

Maybe only crap OSes need import lib but then only crap OSes forget to look in the current dir to find shared libs!!!

If the loader was looking in the current dir for libraries, it would be trivial to poison any application by using a "modified" version of a library it uses. There are even viri/rootkits for Linux that use this and ld_preload mechanism to infect the system. If a user wants to alter the library path, it has to be her/his own decision.

**dimitri** · 25th April 2006, 22:43

Originally Posted by wysota

If the loader was looking in the current dir for libraries, it would be trivial to poison any application by using a "modified" version of a library it uses.

Actually isn't this a misundesrtanding? As far as I know, on Windows the loader looks for DLLs in the application directory, not the current directory. This looks like a good idea and I don't think there are related security issues.

**wysota** · 25th April 2006, 23:10

What if you make a link to the application and somehow force the directory containing the link to be in the path before the directory containing the proper binary (without a poisoned lib in the same directory) or even execute the link yourself on purpose? Making a hard link (I don't know what about a symbolic one) will surely change the "application directory" which opens the security hole again.

**dimitri** · 26th April 2006, 20:05

Originally Posted by wysota

What if you make a link to the application and somehow force the directory containing the link to be in the path before the directory containing the proper binary (without a poisoned lib in the same directory) or even execute the link yourself on purpose? Making a hard link (I don't know what about a symbolic one) will surely change the "application directory" which opens the security hole again.

This cannot happen on Windows, can it?

**krawek** · 26th April 2006, 00:09

Originally Posted by dimitri

Actually isn't this a misundesrtanding? As far as I know, on Windows the loader looks for DLLs in the application directory, not the current directory. This looks like a good idea and I don't think there are related security issues.

Windows? ...