[Kst] Kst 2.0 Install and Settings locations
mike.fenton at torchmobile.com
Wed Jul 15 19:56:24 CEST 2009
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
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.
More information about the Kst