summaryrefslogtreecommitdiff
path: root/daemon
Commit message (Collapse)AuthorAgeFilesLines
* afc: Handle permission denied errorBastien Nocera2020-02-111-0/+4
| | | | | | | The new string is not a string freeze breakage, it's already used in a number of other backends. Closes: #453
* afc: Remove unused error code conversionBastien Nocera2020-02-111-64/+0
| | | | We're doing it manually now.
* afc: Simplify setting error codesBastien Nocera2020-02-111-10/+7
| | | | | | | | | We don't need to go to another function to get an error code when our switch function does that already. The "unhandled" AFC errors are now slightly less precise, but it's still possible to get the meaning of that code from the AFC headers directly (for developers), and not visible for end-users anyway.
* google: Changed copy, move and push to enable overwriting filesMayank Sharma2020-01-311-110/+487
| | | | | | | | | | | | | | | | | | | | Until this commit, copy and move operations weren't capable of performing an actual overwrite of file contents and used to report an error (G_IO_ERROR_NOT_SUPPORTED). This commit adds the functionality to perform an overwrite operation if there exists another file with the same title in the destination directory. This behaviour is desired because it conforms to how normal copy/move operations happen in normal POSIX world. Since, multiple files with same title can exist in destination folder, the copy/move operation now explicity checks and only allows the overwrite operation in case there exists a single file with same title as the source file, otherwise it performs a blind copy/move. (Blind copy here means that a completely new file gets created with same title as source in case of copy, whereas for move the source file simply gets moved). The push function has been modified as well to behave similar to copy/move.
* google: Fixed a bug in copy function which caused crash after renameMayank Sharma2020-01-311-18/+41
| | | | | | | | | | | | | Copy function had the classic time-of-check-to-time-of-use (TOCTOU) bug with the source_entry, which resulted into backend crash due to an entry getting invalidated between two uses. More precisely, we used to check for `existing_entry` using `resolve_child()` which internally calls `rebuild_dir()`. At the beginning of function, we resolve `source_entry`, but if resolve_child rebuilds the directory, our initial reference to source_entry will get freed, resulting into a crash. This commit refactors some of the copy function's code to fix this issue.
* build: Bump libgdata dependency to support latest featuresMayank Sharma2020-01-311-16/+0
| | | | | | | | | libgdata API has been augmented with GDataDocumentsProperty API in the latest release 0.17.11. Since, we're using that API to support copy/move operations, we bump the required dependency version accordingly. We also remove the HAVE_LIBGDATA_* ifdefs since we require libgdata version >= 0.17.11 for the google backend to work properly.
* google: Fix make_directory to create folders with volatile entriesMayank Sharma2020-01-311-1/+43
| | | | | | | | | | | While copying a folder recursively, nautilus calls make_directory operation with the ID of the folder (instead of the title). Although this successfully copies the folder (and its contents too), the titles of all the folders (nested within) are lost. We fix this behaviour of make_directory by checking if the basename is some other folder's ID, and conditionally inserting Source_ID_Property and Parent_ID_Property on the new folder (to create a volatile entry).
* google: Added vfunc for move operationMayank Sharma2020-01-311-0/+234
| | | | | | | | | | | | | | | Earlier, google-drive backend relied on copy/delete fallback to perform the move operation. This operation would atleast require 2 HTTP requests to the Drive API and in the cases of trying to move directories, it won't even succeed (non-empty directory deletion is disabled). We now add vfunc for proper move operation which can move files/directories in a single HTTP request. Since, update operation on file/directory supports writing to the "parents" array, this operation uses `gdata_service_update_entry ()` to update the parents of file/directory to be moved. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/8
* google: Improved debug info being logged while insert/delete/queryMayank Sharma2020-01-311-2/+5
| | | | | | | | | | query_info operation is the most called operation, and generally gives a good idea about the state of cache before and after any other operation. We now log the whole cache while doing query_info operation. Also, some other debug information in `insert_entry_full` and `remove_entry_full` has also been improved, i.e. it now logs conditionally while inserting/removing any entry.
* google: Added "GVFS_GOOGLE_DEBUG" env var to log all the entries in cacheMayank Sharma2020-01-311-0/+35
| | | | | | To better check the state of cache before and after a copy operation is performed, we have added a function which checks for "DEBUG_CACHE" environment variable (any value) and logs all the entries to console.
* google: Fix in-fs copy operation using stored volatile pathsMayank Sharma2020-01-311-46/+367
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Owing to the loss of filename, the copy operation was disabled a long time ago in (https://bugzilla.gnome.org/show_bug.cgi?id=755701). Normally, for POSIX based systems, copying `/file1` to directory `/folder1` is done by doing copy ('/file1', '/folder1/file1'). Since, google drive backend uses IDs as filenames (which are not human readable), so doing a copy operation normally should constitute of doing `copy ('/id1', '/folder1/id2')`, but instead GIO being POSIX compliant does `copy ('/id1', '/folder/id1')`. Furthermore, after the copy operation has been done, nautilus performs a `query_info` operation on the path `/folder1/id1` (to check if the file has actually been copied) but since the newly created file inside `/folder1` has the new path `/folder1/id2` (where 'id2' is generated by Drive API) this operation fails resulting in an error and the new file's title being set to `id1` (Loss of titles). To counter this issue, we store `id1` in Properties Resource on the new file being created, and insert a "fake" entry into the cache. This fake entry (`('id1', 'parent') -> GDataEntry`) gives the illusion that the file exists after the copy operation, and hence the `query_info` operation doesn't fail, and copies the file (while retaining title) successfully. This commit enables copy operation and handles most of the quirky cases of Drive, e.g. files having same title in a directory, file being copied over to same folder, etc. Depends upon: https://gitlab.gnome.org/GNOME/libgdata/merge_requests/7 Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/8
* sftp: Fix file ownership when replacingOndrej Holy2020-01-291-32/+152
| | | | | | | | | | User and group are reset when replacing even though G_FILE_CREATE_REPLACE_DESTINATION is not set. Although the backend calls SSH_FXP_OPEN with SSH_FILEXFER_ATTR_UIDGID attribute, the OpenSSH server ignores this attribute in this operation. Let's fix this by the separate SSH_FXP_FSETSTAT call. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/418
* smb: Improve enumeration performanceOndrej Holy2019-11-051-8/+37
| | | | | | | | | | | | The samba backend calls stat for each file during the enumeration job. Unfortunately, this is significantly slower with the recent samba versions. However, smbc_readdirplus2() has been recently added and it can be used to improve the performance as all the necessary info is transferred in one network request. Let's use smbc_readdirplus2() if available. See: https://gitlab.com/samba-team/samba/merge_requests/302 Relates: https://gitlab.gnome.org/GNOME/gvfs/issues/306
* daemon: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+4
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* smb: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+8
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* sftp: Don't set a content-type that isn't certainBastien Nocera2019-10-111-3/+6
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* nfs: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+4
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* mtp: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+4
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* gphoto2: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+5
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* dav: Don't set a content-type that isn't certainBastien Nocera2019-10-111-5/+10
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* afc: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+4
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* afp: Don't set a content-type that isn't certainBastien Nocera2019-10-111-2/+4
| | | | | | Don't ignore the result_uncertain flag from g_content_type_guess() as it might cause nautilus to incorrectly think that a particular file is of a certain type, and never check its magic.
* smb: Move variable to block where it's usedBastien Nocera2019-10-111-3/+1
| | | | | content_type was only used and initialised inside this block, so move it there.
* dav: Add support for services with IPv6 link-local addressesOndrej Holy2019-10-111-1/+13
| | | | | | | | | | The mount operation currently fails with "Invalid argument" error if GVfsDnsSdResolver returns link-local IPv6 address. This can quite easily happen also when using File Share functionality provided by GNOME. It fails because the link-local addresses requires interface to be specified. Let's append the interface in them to fix this issue. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/423
* dav: Remove brackets from IPv6 address before useOndrej Holy2019-10-101-1/+5
| | | | | | This is follow up of commit d8556a0, which removes brackets when mounting over dav/davs schemes, however, the same fix is also needed when mounting over dav+sd/davs+sd schemes in order to prevent "Invalid URI" error.
* Revert "sftp: Always use port 22 if not specified"Ondrej Holy2019-10-011-5/+7
| | | | This reverts commit 1a38caf8bcb4e02b68f8062319ef7736796a7e64.
* trash: Replace usage of deprecated GTimeVal by GDateTimeOndrej Holy2019-09-201-16/+23
| | | | | GTimeVal is deprecated. Let's replace it by GDateTime in order to prevent the deprecation warnings.
* ftp: Remove usage of deprecated GTimeValOndrej Holy2019-09-201-5/+6
| | | | | GTimeVal is deprecated. Let's remove it in order to prevent the deprecation warnings.
* smb: Remove usage of deprecated GTimeValOndrej Holy2019-09-201-7/+4
| | | | | GTimeVal is deprecated. Let's remove it in order to prevent the deprecation warnings.
* mtp: Remove usage of deprecated GTimeValOndrej Holy2019-09-201-2/+2
| | | | | GTimeVal is deprecated. Let's remove it in order to prevent the deprecation warnings.
* http: Remove usage of deprecated GTimeValOndrej Holy2019-09-201-3/+2
| | | | | GTimeVal is deprecated. Let's remove it in order to prevent the deprecation warnings.
* gphoto2: Remove usage of deprecated GTimeValOndrej Holy2019-09-201-7/+4
| | | | | GTimeVal is deprecated. Let's remove it in order to prevent the deprecation warnings.
* dav: Replace usage of deprecated GTimeVal by GDateTimeOndrej Holy2019-09-201-6/+8
| | | | | GTimeVal is deprecated. Let's replace it by GDateTime in order to prevent the deprecation warnings.
* dav: Fix mounting when 403 is returned for the parent folderOndrej Holy2019-09-131-0/+1
| | | | | | | | | | | | | | The recent commit e9653aa9, which allows mounting when 403 is returned instead of 401, broke the backend for the case when authentication succeeded for subdirectory and 403 is returned for the parent folder. The backend doesn't work properly, even though it doesn't return any error from the mount operation. Nautilus just shows "File is of unknown type" and the backend prints errors like "soup_auth_authenticate: assertion 'password != NULL' failed". Let's prevent usage of the workaround from commit e9653aa9 after the first successful auth to fix this issue. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/417
* google: Disable deletion of non-empty directoriesMayank Sharma2019-07-241-0/+35
| | | | | | | | | | | Earlier, we were deleting a directory irrespective of whether it was empty or not. This would cause a permanent deletion of the folder on Drive, and accidental deletions could be catastrophic. `g_file_delete()` states that if a directory is supposed to be deleted, the job should only carry forward to completion if the directory is empty, else it should error out. We fix this behaviour of delete operation in google backend by conforming to GIO's documentation.
* google: Fix crashes when deleting if the file isn't foundMayank Sharma2019-07-241-1/+2
| | | | | | | | | | Currently in delete operation, if the entry gets resolved but parent resolution fails, the jump to `out` label (while handling error) will cause the existing entry's ref_count to decrease by 1 (since `out` label calls g_object_unref on entry). We fix the issue by removing g_object_unref from `out` label and suitably unreffing the entry.
* daemon/meson.build: define gvfs_rpath for libgvfsdaemon.soRobby Workman2019-07-181-0/+1
| | | | | | | | | | | | | | On Slackware development branch with gvfs-1.40.2, I just noticed this: # ldd /usr/lib64/gvfs/libgvfsdaemon.so | grep "not found" libgvfscommon.so => not found After some backtracking, it seems that this first occurred in the switchover from autotools to meson in the 1.36.x --> 1.38.x bump. Big thanks to Cogitri in #gnome/irc.gnome.org for the patience and assistance with troubleshooting this. Signed-off-by: Robby Workman <rworkman@slackware.com>
* google: Fix issue with stale entries remaining after rename operationMayank Sharma2019-07-181-1/+7
| | | | | | | | | | | Currently, whenever we perform a rename operation, we set the `entry`'s title to new display name, but at the time of removal of this entry from cache, we still use the newer title. Hence, each time rename is done, a single stale entry remains. This commit fixes the issue by reverting back the title to the original display name of `entry` and then performing a removal from cache. Fixes: https://gitlab.gnome.org/GNOME/gvfs/issues/410
* google: Do not enumerate volatile entries if title matches idOndrej Holy2019-07-151-4/+19
| | | | | | Currently, the volatile entry is enumerated if its title matches id of another entry. But we don't want to enumerate volatile entries to not confuse our clients. Let's add simple check to prevent this.
* build: Add dependency on gsettings-desktop-schemasOndrej Holy2019-07-111-0/+1
| | | | | | | | Lockdown settings provided by gsettings-desktop-schemas are used in the code, however, gsettings-desktop-schemas dependency is missing, which can lead to "Settings schema 'org.gnome.desktop.lockdown' does not contain a key named 'disable-writing-to-devices'" errors. Let's add the dependency to prevent such errors.
* daemon: Handle lockdown option to disable writingOndrej Holy2019-07-1116-10/+143
| | | | | | Handle the new mount-removable-storage-devices-as-read-only option of org.gnome.desktop.lockdown schema and present AFC, MTP, GPhoto2 devices as read-only if enabled.
* google: Check ownership in is_owner() without additional HTTP requestMayank Sharma2019-07-091-46/+14
| | | | | | | | | | | | Earlier, we were fetching ACL feed of an entry and then checking the ownership by comparing account identity with elements from this feed. This was slow due to Network IO being performed while checking ownership. We now use GDataAuthors on a GDataEntry to get the list of "owners" of the file. We then use the GoaObject stored on GDataGoaAuthorizer to get the account which is being used by GDataService. Finally, we take the email address of account and compare them to check the ownership. This method now runs without anymore additional network requests.
* gvfsdaemon: Only accept EXTERNAL authenticationSimon McVittie2019-06-061-0/+17
| | | | | | | | | | EXTERNAL is the mechanism recommended in the D-Bus Specification for all platforms where it is supported (including Linux, *BSD, Solaris and Hurd), and is the only mechanism allowed by the session or system dbus-daemon in their default configurations. It is considerably simpler than DBUS_COOKIE_SHA1 and relies on fewer assumptions. Signed-off-by: Simon McVittie <smcv@collabora.com>
* gvfsdaemon: Check that the connecting client is the same userSimon McVittie2019-06-061-1/+35
| | | | | | | | Otherwise, an attacker who learns the abstract socket address from netstat(8) or similar could connect to it and issue D-Bus method calls. Signed-off-by: Simon McVittie <smcv@collabora.com>
* admin: Ensure correct ownership when moving to file:// uriOndrej Holy2019-05-311-0/+46
| | | | | | | User and group is not restored properly when moving (or copying with G_FILE_COPY_ALL_METADATA) from admin:// to file://, because it is handled by GIO fallback code, which doesn't run with root permissions. Let's handle this case with pull method to ensure correct ownership.
* admin: Use fsuid to ensure correct file ownershipOndrej Holy2019-05-311-22/+7
| | | | | | | | Files created over admin backend should be owned by root, but they are owned by the user itself. This is because the daemon drops the uid to make dbus connection work. Use fsuid and euid to fix this issue. Closes: https://gitlab.gnome.org/GNOME/gvfs/issues/21
* admin: Allow changing file ownerOndrej Holy2019-05-311-1/+2
| | | | | | | CAP_CHOWN is dropped together with other privilages and thus the backend can't change file owner. This might be probably e.g. in case of copy operation when G_FILE_COPY_ALL_METADATA is used. Let's keep CAP_CHOWN to fix this.
* admin: Add query_info_on_read/write functionalityOndrej Holy2019-05-311-12/+67
| | | | | | | | | | Admin backend doesn't implement query_info_on_read/write which might potentially lead to some race conditions which aren't really wanted especially in case of admin backend. For example, in file_copy_fallback(), g_file_query_info() is used if g_file_input_stream_query_info() is not supported, which in theory means that the info might be obtained from the different file then it is opened. Let's add this missing functionality to prevent this possibility.
* build: Use path strings in include_directoriesIñigo Martínez2019-05-161-1/+1
| | | | | | | | | | Since meson 0.50.0, plain strings can be used rather than include directory objects[0]. Taking advantage of this feature, some include directory objects have been replaced. [0] http://mesonbuild.com/Release-notes-for-0-50-0.html#include_directories-accepts-a-string
* build: Use dictionaries in configuration_data objectsIñigo Martínez2019-05-161-4/+5
| | | | | | | | | | Since 0.49.0[0], a dictionary could be used as a replacement for each key/value pair as if `set` method was called for each of them. Almost all of the `configuration_data` objects have been changed to use a dictionary. [0] http://mesonbuild.com/Reference-manual.html#configuration_data
View Lorry Controller Status