[Kst] Kst 2.0 Install and Settings locations

[Mike Fenton]

Matthew D Truch wrote:
>> On the whole, sounds like a good plan to me, Mike (with Matt's DESTDIR
>> addition).  Can the temporary library search paths included in the
>> binaries' RPATH (ie. the ones needed to run kst from the build location)
>> be stripped upon install?  If not, and if the builder is foolhardy
>> enough to build kst in a world writable location (say /tmp), doesn't
>> this turn kst into a Trojan?  ie. a malicious user will be able to
>> execute arbitrary code as the user running kst by creating a custom
>> library with the name of a libary used by kst (say libc) in the
>> world-writable temporary build location.
>>
>> There are a number of work-arounds for this problem, none without
>> problems themselves.  libtool relinks binaries on install and has funny
>> little shell scripts to get them to work in-place (probably doesn't work
>> on Windows.)  Another option is to have an "installable" build target
>> different from the default, which doesn't add these extra RPATHs but
>> can't be executed in-place.
>>
>> I'm not suggesting kst not be executable from the build location, just
>> pointing out the security implications.  If nothing else, I'd at least
>> insert a note into the README (or whatever) indicating that kst shouldn't
>> be built in a directory which could be re-created by an arbitrary user.
>>     
>
> Huh.  I didn't even think about that.  It would be best if there were an
> option to strip out the RPATHs.  Fedora packaging requirements require
> it (because the buildsystems virtually all generate (build) packages in
> subdirectories of /tmp that Don's fictitious malicious users could
> abuse). 
I'll need to do some RPATH research regarding how qmake makes use of the
QMAKE_RPATHDIR.  The examples I've found so far seem to indicate that it
is handled by qmake directly, but it will require some investigation. 

Mike