On Mittwoch, 11. September 2013 18:07:36 CEST, Pali Rohár wrote:
Now I looked into qt4 source code and default priority is:
1. QLibraryInfo::location(QLibraryInfo::PluginsPath)
2. QCoreApplication::applicationFilePath()
3. QT_PLUGIN_PATH
In addition, in Kontact the output of tha list will likely be:
("/usr/lib/qt4/plugins", "/usr/lib/kde4/plugins", "/usr/bin")
What does eg. not include the ~/.kde part of QT_PLUGIN_PATH (and i guess the
global path is compiled into kapplication)
On Mittwoch, 11. September 2013 17:54:40 CEST, Jan Kundrát wrote:
I'm asking because the in-tree builds shall load the within-the-builddir
plugins prior to loading the systemwide ones.
Given this is mainly about builddir tests, I'd just use rpath resolution
(reading the ELF object is not actually a hack but the proper way to get such
information - it's just of course not portable, but it's a developer
convenience feature -not having to install- as well; i assume that COFF will
know sth. similar)
Otherwise some
YES_I_WANT_TO_SHOOT_MYSELF_BY_LOADING_PLUGINS_FROM_THIS_UNTRUSTED_PATH variable
should still be better than just loading everything next to trojita.exe (since
i still don't see any reason for such setup on other systems)
The security argument by itself is actually weak - if you start doing sth.
stupid as running a production binary from a user writable path, you're screwed
anyway - regardless of whether you can read plugins from there as well: the
binary may be compromised.
That however also implies that breaking this kind of setups in a way still increases
security ("You don't try" ;-)
Cheers,
Thomas
