Re: Call-return interface for file choosers? (and: security using powerboxes)

[David Malcolm <dmalcolm redhat com>]

On Sat, 2005-11-19 at 12:57 +0000, Mark Seaborn wrote:
> I want to create an alternative implementation of GtkFileChooserDialog
> that doesn't implement a file chooser window itself, but instead
> invokes an external, trusted process to provide a file chooser.  This
> is for security purposes -- skip ahead for more on the reasons.
> 
> Basically I want to treat GtkFileChooserDialog as an asynchronous
> call-return interface, so that:
> 
>  * gtk_widget_show() on the GtkFileChooserDialog sends a message to
>    the external process asking it to open a file chooser.  The message
>    will contain the start directory, default file leafname, etc.
>  * When user chooses OK/Cancel, the external process replies and the
>    GtkFileChooserDialog invokes the GtkDialog response signal.
>    The filename is returned so now gtk_file_chooser_get_filename() can
>    return a result.
> 
> Obviously the interface wasn't designed with this in mind.  It is a
> shame that Gtk doesn't also provide a simpler file chooser interface
> that omits control over the dialog box while it is open.  (Contrast
> this with Qt and Windows, which do offer such call-return style
> interfaces.)
> 
> Does anyone have any thoughts on the best way to implement this?  The
> tricky part is that an application can expect a GtkFileChooserDialog
> to be a GtkDialog, a GtkWindow, a GtkWidget, etc., and could
> potentially call the methods these provide.  Is there any way for an
> object to implement these interfaces without it using the usual
> implementation for GtkDialog, GtkWindow, etc.?  If this isn't
> possible, perhaps the simplest thing to do is have
> GtkFileChooserDialog create a dummy window that won't allow itself to
> be shown.

How about a slightly different interface where you work with
buffers/memory mapped files/file handles/something other than filenames?
This way the application doesn't need to be able to open the user's
files for reading/writing; the trusted executable can do this for it.

A naive interface might be something like this:
gboolean foo_open_file (void **return_buffer, size_t *return_size);
gboolean foo_save_file (void *content, size_t size);
which could internally handle the necessary IPC; though obviously this
needs work so that it doesn't block the application's redraws etc etc.


Have you also thought about drag and drop from file managers?  When
someone drags a file to your untrusted application, the application
receives a URL, but it needs some kind of permission to read the file as
well.

[snip]

> 
> Suppose you run Gnumeric to view a spreadsheet you downloaded from the
> Internet.  Gnumeric might not be a malicious program, but suppose it
> has a buffer overrun bug (quite possible considering it's written in
> C), and the spreadsheet exploits that bug.

IMHO Evolution is a better example; it's constantly working with data
from the network, and you rarely need to deal with arbitrary
user-readable files (creating attachments is one of the few cases)...
and it's written in C.

[snip]

Hope this helps

Dave