[Kst] Kst 2.0 Install and Settings locations

[D. V. Wiebe]

On Tue, Jul 14, 2009 at 11:17:58AM -0400, Mike Fenton wrote:
> As per previous conversations / bug reports in the former Kst2 List I
> want to move the discussion here and outline the current desired layouts.
> 
> Settings:
> 
> Rather than write directly to an Ini file which then must be located
> relative to the binary, Kst will make use of the QSettings objects
> ability to properly place the settings in the UserScope in the
> appropriate location depending on the system.  Settings in OpenSUSE are
> stored in ~/.config/kst, and in Windows in the registry.
> 
> ASCII settings - Settings will be added to provide global settings for
> ascii and these will be configurable using a flag on the ascii
> configuration dialog.  These global settings will be used anytime a new
> ascii file is opened, re-opening a specific ascii file will use the
> settings configured on the last time that particular file was opened.
> 
> File Locations on Install
> 
> Note:  This change will only affect linux, Windows/Mac will not be changed.
> 
> The install location will be configurable using the environment variable
> INSTALL_PREFIX, and will default to /usr
> Library install location will be configurable using the environment
> variable INSTALL_LIBDIR and will default to lib
> Plugins will now be installed to INSTALL_PREFIX / INSTALL_LIBDIR / kst
> 
> It will also be possible to continue to run Kst from the build lcoation
> without calling make install as the configured path will be provided as
> an extra location to search and previous search paths will remain.
> 
> Thoughts and comments are welcome,
> Mike

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.

Cheers,
-dvw
-- 
Don Wiebe                                   dvw at physics.ubc.ca
Department of Physics and Astronomy
University of British Columbia
6224 Agricultural Road                      Tele: +1-604-822-2585
University Endowment Lands, BC
Canada   V6T 1Z1                            http://ketiltrout.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kst/attachments/20090714/74f3fe07/attachment.sig