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.
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/libgvfsdbus.so 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…