KDE4 Patch to allow testing/execution of uninstalled kparts/XMLGUI applications

[Friedrich W. H. Kossebau]

Am Mittwoch, 10. August 2005 11:54, schrieb David Faure:
> On Tuesday 09 August 2005 12:36, Friedrich W. H. Kossebau wrote:
> > Am Dienstag, 9. August 2005 03:58, schrieb David Faure:
> > > On Tuesday 09 August 2005 03:30, Adam Treat wrote:
> > > > I understood it to mean a new command line argument that would
> > > > specify the .krcdirs filename.  This way, if the flag isn't present,
> > > > everything takes place as normal.  I can't really see where this is a
> > > > big security improvement, but I could take this approach instead,
> > > > rather than use the current working directory...
> > > >
> > > > It wouldn't mean anything other than the app would have to be
> > > > executed with the a '--resources' command line parameter in order to
> > > > run locally...  Does this sound better to you, David?  Or do you
> > > > think we should just go with the CWD?
> > >
> > > I see so many people run "./kmyapp" and it fails (no menus, no icons
> > > etc.), I think we should make it work out of the box.
> >
> > If they are able to put a "./" before the app they are also able to put a
> > parameter behind.
>
> I think I didn't make my point clear, then ;)
>
> Download the source tarball for any non-kde application, compile, then
> run the binary without installing it. For most non graphical programs it's
> as easy as "./foobar". That's the way to do it - the standard unix way that
> everybody knows.

Well, you make the restrictions to such a pattern yourself: only non graphical 
programs, and then only most of those. ;) And then those programs also work 
if called from some other than their directory. Simply due to having no 
external resources.

> If for a kde app it's more complicated than that, then it defeats the
> purpose IMHO. 

Which purpose? Of quickly compile an app and try it?

Better solution: Integrate support for packet management in "make install" 
instead of throwing files all over the place. With easy support for user 
local installations. That should be the linux way ;)

> Given that we have a solution for making it that easy, we 
> should make it that easy. Why require people to set env vars, or pass
> additional command-line options, when the standard way can be made to work,
> simply by shipping a file together with the sources?

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.

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.

Installed apps have to be called explicitly to use some freshly created 
resources. For this IMO it makes even sense to make the process of using 
uninstalled resources visible, using "kapp --resource wiredplugin.krcdirs".

... seems I miss an alternative solution that fits the needs right now. Sadly 
existing and running code is quite hard to beat. ;) But I really fear the 
proposed solution in its current style will backfire sometime. :(

> > Another idea: Check if the arg0 has "./" before and then
> > take this as the security parameter perhaps?
>
> Might work (except for people who put "." in their $PATH and don't have
> another version of the app installed....)

Sigh ;) Do people really do this?

> > [...]
> > Oh. In which way?
>
> Not sure if that questions was about libtool libraries or about installing
> modified version of libraries to make an executable behave differently?

The latter.

> The latter seems obvious to me (if it's about a build directory, which
> isn't root-owned), and the former is simply "./myexe will use the local
> libs like .libs/libfoo.so, to make it possible to run the app without
> installing it". Oh, and it does that without you having to pass special
> command-line arguments ;)

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?

Perhaps we can at least limit the read .krcdirs to those owned by the same 
user? That should at least limit the admin attack (well, the one against the 
admin) :)

Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050810/e5beaaeb/attachment.sig>