On Wednesday, 11 September 2013 18:25:52 CEST, Thomas Lübking wrote:
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.
As Pali already pointed out, that was a misunderstanding on my side. I
thought he proposed reading from the working directory, but he was actually
proposing reading from the directory where the binary is stored. The former
is dangerious, the latter is safe.
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)
I like rpath/runpath processing, too, but it seems to me that the cost to
pay is too high in this case. Heuristics like "okay, the directory where
the binary is located is *not* the compile-time-specified DESTDIR, let's
launch readelf and read its output to see how the current rpath looks like"
are a bit too much, Or maybe we can go for it on non-Windows, and fall back
to the current binary dir on Windows.
Or just don't bother with this nonsesne and just use the following:
a) if the BINDIR as defined at build time matches the current app's dir ->
load from the compile-time-specified PLUGINDIR (typically app being located
at /usr/bin/ and plugins at /usr/lib/trojita/)
b) otherwise load from the app dir (path to binary, *not* pwd)
But I've laready had my tonight's beer, so perhaps I'm again missing
something completely obvious. Comments welcome.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
