On Wed, 2007-12-12 at 12:05 -0500, David Zeuthen wrote: > Hi, > > I've looked at the GMountOperation class today and I have some security > concerns. Basically, the way I understand how it's supposed to work is > that if you mount something you may need to provide credentials. Also, > I understand a GtkMountOperation subclass is planned that can also fetch > the credentials from gnome-keyring.
That is not quite right. The gnome-keyring communication will happen in the gvfs backends. All we need from the app is to reply to some questions, like "what is the user name and the password? and btw whould we save the password in the keyring?", or "the ssh fingerprint changed, do you trust this new one?". This goes through a GMountOperation for two reasons: 1) We can have multiple implementations of it, for instance a console based text version and a Gtk based UI version 2) It is a way to separate out the lowlevel non-ui code from the X dependent APIs in Gtk and still be able to get good UI integration. For instance, the GtkMountOperation will know the correct parent for the authentication windows, and it can implement things like application modal password dialogs and inhibiting of "cancel" windows while a password is being requested. But I understand your concerns. You want a trusted path from the keyboard to the authenticating entity. I think with some work we can achieve that with the current system. Here is how it currently works: 1) App a wants to mount some gvfs volume, and the app hands gio a GtkMountOperation. 2) We wrap this mount operation in a dbus mount operation that proxies calls to/from the app mount operation to the dbus 3) We pass the object path of this wrapper to gvfs in the mount call 4) when gvfs needs to auth it calls dbus -> wrapper mount op -> gtk mount op -> user dialog -> gtk mount op -> wrapper mount op -> dbus -> gvfs daemon The same kind of wrapper is used on the gvfs side, the backend code just sees a GMountOperation object which converts to/from dbus messages. Now, how can we extend this to add a secure channel and not change the API? One way is to make the GtkMountOperation object implement new interface like GSecureMountOperation. The gvfs mount call would notice that the passed in object implements this and call a different mount operation that somehow returns a secure channel (via fd passing or something) that gets passed into the GSecureMountOperation which spawns a setuid helper. Another alternative is to pass the channel from the GSecureMountOperation with the mount call. On the client side apps will keep doing what they used to (pass gtk_mount_operation_new() to the mount operation) and on the backend side the code would still see a GMountOperation object, it would just proxy things differently. One problem is that GSecureMountOperation probably will need to expose unix specific things (such as fd passing). But we can make this API unix-specific and since the only consumer of it is in Gtk+ and its use of it is hidden this isn't so much of a problem. So, I don't think the current API prohibits a secure authentication dialog, but it would be some work to implement. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
