Proposal: dlopening the file dialog

[John Tapsell]

The file daemon idea is probably not that feasible (people like to
modify the dialogs etc.)  but it would have one big advantage if done
properly - it would let you secure a system much better.

Currently one biggish problem with selinux (for example) is that you
can't currently say "firefox shouldn't write to disk" because the user
might download and save a file.  Using a daemon that popped up a file
open/save  dialog, and then opened the file and somehow passed the
file descriptor back, would mean that you could then use selinux to
stop firefox from opening any file (apart from config files etc).

(I just used firefox as an example to avoid the details about using it
with khtml)

JohnFlux

On 02/04/07, David Faure <faure at kde.org> wrote:
> On Friday 30 March 2007, Lubos Lunak wrote:
> > On čt 29. března 2007, David Faure wrote:
> > > Hmm, only if there are no pointers in the interface.
> > > If the KAbstractFileWidget interface says:
> > >     virtual KToolBar *toolBar() const;
> > >     virtual KComboBox *locationEdit() const;
> > >     virtual KComboBox *filterWidget() const;
> > > then it can't be implemented using IPC....
> >
> >  Of course they can, you just need to try harder :).
> There's even a setCustomWidget(QWidget*).
> (But of course we could remove that argument from the kfiledialog
> constructor and require using libkfile for that feature)
>
> >  The same applies to your 'extra daemon' and probably 'bad integration'
> from your other mail (not
> > sure about the second one, what did you have in mind specifically?).
> Well you know, process A asks process B to open a modal dialog.
> Process A uses a nested event loop around the dbus call so that the
> application repaints
> but blocks user interaction, no problem. But how do you ensure that clicking
> in A's windows
> brings up B's modal dialog, like modal dialogs usually do? I'm sure you have
> some X-level hacks
> to do that, but I'm also quite sure they are not portable ;-)
> All this kind of issue can be avoided completely if we dlopen the file
> dialog instead of
> delegating it to another process.
>
> > Ok, maybe not completely, but to a sufficient level, I have some
> proof-of-concept
> > code somewhere that can do things like
> > http://ktown.kde.org/~seli/download/qtkde/scribus_gettext.png (Scribus is
> > Qt-only).
> I think we can add a qt-only interface to kfilemodule, no need for IPC.
>
> >  I'm mainly asking because of the external filedialog because of
> > interoperability/kde3vs4compatibility/whatever ideas from Malaga. If you
> > remember please CC me on the commit of the abstract interface, I'd like to
> > check if there isn't some obvious problem that'd prevent this in the
> future
> > if it ever becomes more than just theory.
> I just committed it all - rev 649211.
>
> --
> David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
>