GNOME Bugzilla – Bug 773053
Cannot access file owned by other user via gvfs mount
Last modified: 2017-03-23 15:56:55 UTC
Steps to reproduce: 1. dd if=/dev/urandom of=/tmp/rand bs=1024 count=1 2. upload /tmp/rand to drive as user A 3. As user A, in drive share rand with user B with edit access 4. Set up drive access via gvfs for user B and gvfs-mount 5. cat /run/user/$UID/gvfs/google-drive\:host=HOST\,user=USER_B/$(gvfs-info google-drive://USER_B@HOST/rand | grep id::file: | cut -d ' ' -f 4) Expected result: Command in step (5) prints random file contents Actual result: the file in the mount has empty contents Additional notes: * gvfs-info shows correct info for file. * gvfs-cat shows correct file contents. * The same file, uploaded directly to user B, shows correctly in the mount This is frustrating because non doc/sheet/slides/forms cannot have the owner changed (https://support.google.com/drive/answer/2494893). My use-case is to accesses a shared password manager file stored in drive. This necessitates using the mount due as the password manager software can only access the filesystem. OS: Debian stretch (testing) gvfs version: 1.28.2
"gvfs-info shows correct info for file" is not quite true: File owned by current user: $ gvfs-info google-drive://USER_B@HOST/rand_owned display name: rand_owned edit name: rand_owned name: rand_owned type: regular size: 1024 uri: google-drive://USER_B@HOST/rand_owned attributes: standard::type: 1 standard::is-hidden: FALSE standard::is-symlink: TRUE standard::name: rand_owned standard::display-name: rand_owned standard::edit-name: rand_owned standard::copy-name: rand_owned standard::icon: application-octet-stream, application-x-generic standard::content-type: application/octet-stream standard::fast-content-type: application/octet-stream standard::size: 1024 standard::symlink-target: /0B3IhEJkUX58sMmxGMEpjTmsyMEU standard::symbolic-icon: application-octet-stream-symbolic, application-x-generic-symbolic, application-octet-stream, application-x-generic standard::is-volatile: TRUE etag::value: "x5Bvrsrg2___c4vUvatrLj8c7hQ/MTQ3NjY1MDk0MjIxNQ" id::file: 0B3IhEJkUX58sMmxGMEpjTmsyMEU id::filesystem: google-drive:host=HOST,user=USER_B access::can-execute: FALSE access::can-delete: TRUE access::can-trash: FALSE access::can-rename: TRUE time::modified: 1476650942 time::access: 1476650942 time::created: 1476650942 owner::user: USER_B owner::user-real: USER B NAME File only shared: $ gvfs-info google-drive://david@newg.as/rand display name: rand edit name: rand name: rand type: regular size: 0 hidden uri: google-drive://USER_B/rand attributes: standard::type: 1 standard::is-hidden: TRUE standard::is-symlink: TRUE standard::name: rand standard::display-name: rand standard::edit-name: rand standard::copy-name: rand standard::icon: application-octet-stream, application-x-generic standard::content-type: application/octet-stream standard::fast-content-type: application/octet-stream standard::size: 0 standard::symlink-target: /0BzwyZDnFu1z-ZXdaOVpHSGZZN2M standard::symbolic-icon: application-octet-stream-symbolic, application-x-generic-symbolic, application-octet-stream, application-x-generic standard::is-volatile: TRUE etag::value: "x5Bvrsrg2___c4vUvatrLj8c7hQ/MTQ3NjY0OTU0OTU1NA" id::file: 0BzwyZDnFu1z-ZXdaOVpHSGZZN2M id::filesystem: google-drive:host=HOST,user=USER_B access::can-execute: FALSE access::can-delete: FALSE access::can-trash: FALSE access::can-rename: TRUE time::modified: 1476649549 time::access: 18446744073709551615 time::created: 1476649506 owner::user: USER_A@HOST owner::user-real: USER A NAME Note that the size for the the shared file is zero. It is possible that when accessing via the mount, this size is used to determine how much to output, but gvfs-cat is fetching the file regardless of the incorrect "0" size. My best guess is that size is showing up as "zero" as it counts zero usage towards USER_B's storage quota, or just a plain bug. Also it is unclear why the shared file has the hidden bit set (perhaps because I haven't "added to My drive".
Even after clicking "add to my drive" on "rand" as user_b it still shows up as hidden in gvfs-info.
It does appear gdata_documents_entry_get_quota_used is being used as file size. libgdata doesn't provide a similar true file size function. I'm looking at the feasibility of adding one.
Any such improvements might have to wait untill #684920 is fixed as the old drive API isn't even documented. The new API definitely has the true size, we just need to make sure libgdata exposes and gvfs uses it.
Thanks for your bug report, although you mentioned more issues: - File size for shared files is 0, but should be rather unset, or set to the real value... - This is bug and should be fixed (I've seen that you provided patch for libgdata - Bug 773057, thanks)... - It seems fuse daemon doesn't work well if file size is unknown/zero. Not sure where is the problem, because vfs_read is called and 4096 bytes is read. However, vfs_release is called after it. Maybe kernel has a problem with it? - This is also bug, but not sure we can do something with it... - Shared files are hidden. It is expected, unless you add them on your drive. Do you really have some files in "My Drive" folder, or any other folder, which are marked as hidden? - This should work correctly right now...
Created attachment 337848 [details] [review] google: Do not set file size for shared files Libgdata doesn't provide API to obtain real file size for shared files and gdata_documents_entry_get_quota_used returns zero. Don't set file size for the shared files at all...
I didn't mean the hidden file thing as a bug, just drive-by observation in case it turned out to be relevant. The file size & fuse issues both combine to cause the symptom which I am reporting. I suspect fixing either would work, and as you say the file size one seems easier to fix for gvfs. In #773057 we are adding gdata_documents_entry_get_file_size to provide the file size. While it'll take a bit of time to be available, it seems the most robust solution.
Review of attachment 337848 [details] [review]: Hmm, has_parent != is_shared...
Created attachment 339314 [details] [review] google: Fix file size Thanks for the gdata_documents_entry_get_file_size patch. Let's use it in GVfs once it is available...
Created attachment 348472 [details] [review] google: Fix reported file size Ligdata recently added API to obtain a real file size. Use gdata_documents_entry_get_file_size if libgdata 0.17.7 is available instead of gdata_documents_entry_get_quota_used, which returns 0 in some cases (e.g. shared files).
Review of attachment 348472 [details] [review]: Thanks for the fix, Ondrej! Looks good to me and works as advertised with the shared items in my Drive.
Thanks for the review! Attachment 348472 [details] pushed as d22a127 - google: Fix reported file size I am going to push it for stable branches also...