Proposal: dlopening the file dialog

[jos poortvliet]

Op Monday 02 April 2007, schreef David Faure:
> On Monday 02 April 2007, John Tapsell wrote:
> > The file daemon idea is probably not that feasible (people like to
> > modify the dialogs etc.)
>
> That's not a problem - the current design already distinguishes two kinds
> of uses: you want a standard file dialog, it's dlopened. You want a
> customized one, you have to link to libkfile.
> A daemon would only ever replace the first solution, not the second one.
>
> > 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 fail to see how this is relevant to dlopening vs a daemon. The dlopened
> module could do just the same, couldn't it?

Do you know Plash? http://plash.beasts.org/

This is (I think) what John was/is talking about. Plash needs the file-open 
(and save) dialog in a seperate process. This process gives read/write 
priviliges to another process (the one requesting to open a file). A user 
thus automatically explicitly gives access to a file (and just that file). 
Access to other files is always prohibited, thus the app is sandboxed.

Klik is thinking of using it http://klik.atekon.de/wiki/index.php/Plash as one 
of the options http://klik.atekon.de/wiki/index.php/Virtualization_Options

grtz

-- 
Jos Poortvliet
KDE-nl
http://www.kde.nl
http://www.kde.org

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
-------------- 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/20070402/a8906764/attachment.sig>