Description: I have odt files stored on a directory shared by multiple computers with multiple users. The directory is shared using sshfs and the computers are running Linux (not all the same version). The odt files are created owned by some_user_name:my_odt_user_group and have read/write permissions for the owner and group members, and read permissions for non group members. However, when a user on a remote computer edits one of the files using LibreOffice Calc and saves the changes, the file ownership changes to that_other_user:that_other_user . That is, both user and group are changed. 1) change to group breaks file sharing; other members of the group can no longer make changes to the file 2) change to the user is not a functional problem for me but still a bug Steps to Reproduce: 1. create an odt file using calc; set file group to some group and give read/write access to group 2. mount its directory over ssh on another PC using a different user account in the same group 3. edit the file and save 4. go back to the first PC and try to edit the file Actual Results: file was opened "read-only" on the original PC. looking at the filesystem showed that the file's ownership had changed Expected Results: file ownership should have remained as it originally was. I believe this if this were done correctly, the file would have opened "read-write" Reproducible: Always User Profile Reset: No Additional Info: This is only from one of the PCs; the other has a more recent version see above Version: 5.1.6.2 Build ID: 1:5.1.6~rc2-0ubuntu1~xenial10 CPU Threads: 8; OS Version: Linux 4.15; UI Render: default; Locale: en-GB (en_GB.UTF-8); Calc: group
I am unsure if this could be improved, given the logic of the save. It is not "open the file, then edit bytes in it": for safety, it is "create a new file next to the opened file, named something like tmp1234; write bytes there; then, after successful write, so that we know that no failure happened in the middle of write, remove or rename the first file (the rename can be when backups are kept), and rename the tmp1234 to the old name". There is ReplaceFileW API *on Windows* to "impersonate" the file in such a situation; its use was implemented in commit c9343988204ee3e9889f3cc833adbbaca83e53e6 "tdf#119238: keep replaced file's identity when renaming docfile". I don't know if there is something similar on Linux, or if it's even possible with the remote filesystems (the Windows API also actually works locally; it would be a vulnerability to allow a remote process to impersonate other users on file server).
It would be an immediate improvement for my use case if the group were preserved, even if the user were not "impersonated". Seems to me (but I claim zero expertise) that the file-save would be no less safe if: "create a new file next to the opened file, named something like tmp1234; write bytes there; then, after successful write, so that we know that no failure happened in the middle of write, open the [original] file, then edit bytes in[to] it"