KDE4 Patch to allow testing/execution of uninstalled kparts/XMLGUI applications
hans_meine at gmx.net
Wed Aug 10 14:22:31 BST 2005
On Wednesday 10 August 2005 13:50, Friedrich W. H. Kossebau wrote:
> Because it has a security flaw? This solution enables far more usage
> patterns than the usage patterns it was invented for. And there are some,
> as described, that we should not lightheartedly accept IMHO.
I don't like it as-is, either.
> What is to be achieved: Tell installed and uninstalled apps about
> uninstalled resources, right?
> Nice to have: The app should automatically take up a description of the
> uninstalled resources in the cwd. Makes sense for uninstalled apps, doesn't
> for installed. Still with me?
> Uninstalled apps are in a relation to their uninstalled resources known at
> compile time. So perhaps they could be compiled in? But after an
> installation this does not make sense anymore. Idea dropped.
One idea you did not mention is that used by libtool. It installs a wrapper
script that sets up environment variables to find the uninstalled libraries.
IMO the best way would be to enhance exactly these existing scripts (which
will never be installed) to make the program find the extra resources.
(The easiest way being a "KDE_USE_LOCAL_RESOURCES=1" variable firing the
posted code that stat's .krcdirs.)
I must have overlooked something, probably in conjunction with kparts.
Still, I'd propose to guard Adam's code with such a variable.
> I know close to nothing about libtool and cannot make too much out of your
> comment, excuse me. Is libtool only used by KDE apps or all? And does this
> really mean that libtool enables to circumvent the cwd protection? So one
> could fool an admin by one's personal glibc version? Or what is the scope
> of libtool?
I guess that the above script was meant. Yes, you can use your own glibc by
changing LD_LIBRARY_PATH (AFAICS), but how would you fool an admin?
It still runs with your UID, and you can run/code basically anything for
More information about the kde-core-devel