Bug 138252 - LibreOffice doesn't preserve facls (create new files on save and ignores old facls)
Summary: LibreOffice doesn't preserve facls (create new files on save and ignores old ...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-11-16 10:31 UTC by Edgar Hoch
Modified: 2020-12-24 07:59 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edgar Hoch 2020-11-16 10:31:01 UTC
Description:
When LibreOffice saves a file, it removes the old file and creates a new file.
But it doesn't preserve facls.

Instead, LibreOffice should either write the new content in the same file (creating a backup file as a new file before modifying the original file), or create the new file with exact the same permissions, facls, SELinux context, etc. as the old file.



Steps to Reproduce:
1. Open LibreOffice.
2. Create new LibreOffice document and save it
   (on a local file system, so we can use setfacl and getfacl)
3. Check facls:
   getfacl filename
4. Set some facls, for example
   setfacl -m g:wheel:rw- filename
5. Check facls:
   getfacl filename
6. Note which inode the file has, for example with stat:
   stat filename
7. Open the file in LibreOffice, change something, so it is modified, and save it.
8. Check if the file has the same or another inode now:
   stat filename
9. Check facls:
   getfacl filename



Actual Results:
FACLs are lost.

Expected Results:
FACLs are preserved.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.4.7.2
Build-ID: 6.4.7.2-3.fc32
CPU-Threads: 8; BS: Linux 5.8; UI-Render: Standard; VCL: gtk3; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
Comment 1 Stephan Bergmann 2020-11-17 14:17:28 UTC
capturing the recent discussion on FreeNode #libreoffice-dev:

> Nov 17 14:52:36 <sberg_> vmiklos, I tend to remember you once added code (in sfx2 or similar) to preserve certain attributes of the original file when a new version of a document is saved, similar to how tdf#138252 now asks for extended ACLs to be preserved on Linux?
> Nov 17 14:52:38 <IZBot> LibreOffice-Calc normal/medium UNCONFIRMED LibreOffice doesn't preserve facls (create new files on save and ignores old facls) https://bugs.documentfoundation.org/show_bug.cgi?id=138252
> Nov 17 14:54:39 <vmiklos> sberg_: IsFileMovable() in sfx2/source/doc/docfile.cxx this to decide if we can move the tmp file to the final destination or we have to copy the bytes over
> Nov 17 14:55:43 <vmiklos> osl::File::replace() is what it uses, which is just a plain rename() in the linux case, there is some better "replace and inherit the destination properties" api on windows.
> Nov 17 14:57:06 <sberg_> vmiklos, I think I'd thought of something else (a place that copies the Unix user/group/other permission bits, say), but I may well misremember anyway
> Nov 17 14:58:12 <vmiklos> sberg_: that GetDefaultFileAttributes() + osl::File::setAttributes() at the same place where IsFileMovable() gets called?
> Nov 17 14:58:13 <sberg_> vmiklos, ah, that "// Adjust attributes" stuff later in that file...
> Nov 17 14:58:23 <sberg_> yeah :)
> Nov 17 14:59:12 <vmiklos> i don't have a strong opinion on that file moving, it's possible we should just give up on this on linux, and make it windows-only, where we have a good api to replace content..
> Nov 17 15:00:13 <noelgrandin> I thought I saw something on the kernel mailing list about one of the filesystems implementing this kind of thing
> Nov 17 15:01:19 <sberg_> vmiklos, benefit is probably that it makes it harder to get a file truncated in the middle if things go wrong midway
> Nov 17 15:02:38 <noelgrandin> those of us with flakey power thank the people who implement such things
> Nov 17 15:03:27 <vmiklos> sberg_: yes, i though this is really standard way of doing things, but then people complained about all sort of corner-cases :) so now i'm less sure this was a good idea after all.