Interface suggestion: gvfs

Hello! I maintain the deja-dup snap and was looking at confining it (rather than continuing as a classic snap).

One piece that is missing is the ability to talk to the org.gtk.vfs daemon. This means I can’t mount, read, or write to (for example) an sftp:// or webdav:// URL through gio. Or query gvfs to see which removable drives are connected.

It would be nice if there were an interface that allowed that.

Hi @mikix!

Just wanted to mention that this request was not ignored. gvfs is a bit problematic, but it is something we should look into and I’ve added it to the list of things to look at in the next couple batches of policy updates.

1 Like

Any progress on a gvfs interface? I’m looking longingly at cool confined features like extensions and layouts.

I don’t think there has been any work on it, no.

With that said, maybe xdg-desktop-portal could fill your needs now? The document portal code now supports sharing directory trees with a sandboxed application, rather than single files only. If the use case fits into the “let user select a location to write or read backups”, then perhaps that might now work?

Ah interesting, I hadn’t noticed them adding directory support!

That would probably be enough for my needs. But unfortunately, the documents portal still don’t allow non-local file support. Ah well.

I haven’t tested gvfs remote file systems via the document portal. If they don’t work, I wonder if that could be considered a bug?

In theory, it should be possible to chain xdg-document-portal’s FUSE file system to gvfs’s FUSE file system to the appropriate gvfs backend. It’s quite possible that the URI -> gvfsd-fuse file name is being skipped though.

I don’t know as if it’s a bug - I think it gets complicated because of the mount process. Document permissions are persistent, but there are some UX questions probably, about how and when to prompt the user for a password if necessary to mount a location that the app was previously granted permission to.

Maybe needs some thinking and/or a new API call on the portal. Not sure.

Gimp uses GVFS to access the help documents online via HTTP. The current blocker is:

= AppArmor =
Time: Apr 18 17:59:34
Log: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/gtk/vfs/Daemon" interface="org.gtk.vfs.Daemon" member="GetConnection" mask="send" name=":1.698" pid=1753016 label="snap.gimp.gimp" peer_pid=115108 peer_label="unconfined"]
DBus access

It would also be nice to include the gvfs-backends (unless these aren’t needed and we can just stage gvfs on it’s own) in the gnome-platform snaps so that we don’t need to hijack the desktop-launch script - at the moment, I’ve added custom code to desktop-launch that symlinks $SNAP/usr/lib/x86_64-linux-gnu/gio/modules/ in addition to the already present symlinking of $SNAP_DESKTOP_RUNTIME/usr/lib/$ARCH/gio/modules/*.so into the cache location before running gio-querymodules (cache location is $XDG_CACHE_HOME/gio-modules).

Did this request get any further? I’m still unable to get GIMP to show the online help documentation due to the denial in my previous comment…