GNOME Bugzilla – Bug 590007
Remount operation
Last modified: 2018-05-24 11:56:50 UTC
The GIO subsystem was designed to allow authentication only during mount operation (i.e. only one place with clear result mounted/not-mounted). Once a resource is mounted, it's not possible to re-authenticate or remount (modify) the mount in any other way. Now imagine you have an ACL-enabled resource where every folder can have different permissions and/or is possible (from backend side) to do re-authenticate as a different user. One common use case is WebDAV, based on HTTP authentication. Auth request can come on first write attempt, thus undetectable during mount (first read operation). This breaks gnome-user-share usability when password protection is only set for writing. So we were thinking about several ways to work around this issue with as little API changes as possible and came up with this solution: - introduce new G_IO_ERROR_NEEDS_REMOUNT - introduce new g_file_remount () with arguments similar to g_file_mount_mountable () or g_file_mount_enclosing_volume (), i.e. passing GMountOperation instance to handle new auth request. If unhandled, G_IO_ERROR_NEEDS_REMOUNT would just mean G_IO_ERROR_PERMISSION_DENIED, only giving a hint that remount/re-authentication is possible. We can set some nice verbose error message too. Applications should handle this error similarly to G_IO_ERROR_NOT_MOUNTED, only calling g_file_remount (). Looking at Nautilus code, it should not be difficult to support this feature.
Thinking about it, we can easily use this to force remount on stalled network connections, e.g. after resuming computer from hibernation. Some backends like SMB suffer from this issue. It's a better way than just forcing user to manually unmount first and mount again (e.g. from bookmark), IMHO.
Sounds reasonable in general. About g_file_remount, would it be too confusing to just use g_file_mount with a G_MOUNT_REMOUNT flag ? I'd hate to introduce yet more mounting-related api...
(In reply to comment #2) > Sounds reasonable in general. About g_file_remount, would it be too confusing > to just use g_file_mount with a G_MOUNT_REMOUNT flag ? I'd hate to introduce > yet more mounting-related api... Could be, the GMountMountFlags is used in both g_file_mount_mountable () and g_file_mount_enclosing_volume () but that shouldn't matter.
I think G_IO_ERROR_NEEDS_REMOUNT sounds good. Maybe it would be better to call it G_IO_ERROR_INSUFFICIENT_PERMISSION since that is more general. E.g. it would mean PERMISSION_DENIED but also means that you might be able to get the permission. We probably want to use the same error for the PolicyKit integration bits that Alex talked about here http://blogs.gnome.org/alexl/2007/11/23/file-operations-in-nautilus-gio-and-adventures-in-the-land-of-policykit/ e.g. the idea is that e.g. g_file_replace() could return INSUFFICIENT_PERMISSION and then you could do elevated_file = g_file_new_with_elevation (file); and then do you op on elevated_file (GVfs would implement an extension point to make that GFile constructor work). Or maybe it is better to just use NEEDS_REMOUNT. Then for the PolicyKit integration we'd introduce a NEEDS_ELEVATION error code. Discuss. Btw, not so sure we need a G_MOUNT_REMOUNT flag, that sounds a bit confusing given that it would completely make g_mount_remount() obsolete.... Why can't applications just do mount = g_file_find_enclosing_mount (file, cancellable, &error); if (mount != NULL) { g_mount_remount (mount, flags, mount_op, cancellable, callback, user_data); }
David cleared up my confusion on irc. There is no need for the flag, because the required api is already there: g_mount_remount And there won't be any duplication of the mount api on gfile, gvolume, etc, because the required api is on the mount object, anyway. So my flag proposal doesn't make sense, ignore it.
The proposed solution would work e.g. for share where is public and private part and you are traversing the filesystem and wanted to see the private part, after you mounted the public one... However there are also shares, where some operations could be privileged. So everything is publicly accessible for reading only and if you want write, you have to authorize (this is also common for webdav)... Example: We want create new FILE, but g_file_create (FILE) failed due to insufficient permissions, however g_file_remount (FILE) won't work, because FILE doesn't exist yet and thus webdav doesn't ask for password if we try to access this FILE... See: https://bugzilla.redhat.com/show_bug.cgi?id=1060352 https://bugzilla.gnome.org/show_bug.cgi?id=549415
I can imagine that the example, I mentioned in comment 6, could by solved using existing api. Idea: Write operation fails with G_IO_ERROR_NEEDS_REMOUNT and backend set set some internal flag, e.g. store_credentials_on_remount_flag. Client execute g_mount_remount and backend ask for password if store_credentials_on_remount_flag is set (even though credentials are not needed during mount). Backend accepts credentials without error (even though credentials could be wrong) and store them. Client then retry the write operation and backend use provided credentials. It succeeds if the credentials are valid, or fails with G_IO_ERROR_NEEDS_REMOUNT if not. Just a note that g_mount_remount interface exists as mentioned before, but it seems it doesn't have any implementation yet (neither for unix mounts neither for daemon mounts).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/235.