LibreOffice flatpak doesn't stop "saving" where it can't write to, then "deletes" the "file" that never existed

[WineBottles]

Description: Currently LibreOffice flatpak does not provide an error/warning prompt when it is not able to save to a location it does not have access to view flatseal/bubblewrap.

What occurs, is the user is able to use File menu Save as and pick any location (even if LibreOffice flatpak does not have access) to save in the file picker window that appears. Even if you use that file picker to do another save as or open you can see the file that was created along with the .lock file.

However, if the user looks with their own integrated file explorer which is Dolphin for me they will see the files were never actually created. Neither the regular file or .lock.

This makes me curious if this is a bug in: 1) LibreOffice Flatpak 2) Integrated file picker/explorer 3) Bubblewrap/Flatseal 4) Flatpak itself

It is concerning that LibreOffice flatpak "creates" a file that can be seen in the file picker/explorer pop up but not outside of it.

Steps to Reproduce:

1. Create a document in LibreOffice Calc flatpak
2. Write some stuff
3. Click File and Save as in the menu bar. "save" it to a location there is no access via flatseal LibreOffice Calc "thinks" the file is saved there as the file picker suggets
4. Navigate to that location in your file explorer (Dolphin for me).
5. Close LibreOffice Calc flatpak
6. Reopen LibreOffice Calc flatpak
7. The file never existed in LibreOffice Calc apparently
8. Cry because you lost hours of work.

Actual Results: The file is nowhere to be found.

Expected Results: LibreOffice would warn the user that they are not able to save to that directory due to lacking permissions in flatseal/bubblewrap.

Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes

Additional Info: Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.15.16-hardened1-1-hardened (64-bit) Graphics Platform: X11

[Erick555]

Click File and Save as in the menu bar. "save" it to a location there is no access via flatseal LibreOffice Calc "thinks" the file is saved there as the file picker suggets

I'm unable to reproduce this part. LO doesn't use portal so in the file picker it shows only directiories it can write into (unless you made something read-only via flatseal). Could you postflatpak info -M org.libreoffice.LibreOffice output?

Where exactly you are saving those files? If it's /tmp then it makes sense as flatpak has separate /tmp from host which is discarded after app close.

[WineBottles]

Click File and Save as in the menu bar. "save" it to a location there is no access via flatseal LibreOffice Calc "thinks" the file is saved there as the file picker suggets

I'm unable to reproduce this part. LO doesn't use portal so in the file picker it shows only directiories it can write into (unless you made something read-only via flatseal). Could you postflatpak info -M org.libreoffice.LibreOffice output?

flatpak info -M org.libreoffice.LibreOffice
[Context]
shared=ipc;
sockets=x11;wayland;
devices=dri;
filesystems=/home/USERNAME/Downloads;!host;

[Session Bus Policy]
com.canonical.AppMenu.Registrar=talk
org.gtk.vfs.*=talk
org.libreoffice.LibreOfficeIpc0=own

[Environment]
GIO_EXTRA_MODULES=/app/lib/gio/modules
GTK_THEME=Adwaita:dark
JAVA_HOME=/app/jre
LIBO_FLATPAK=1

Where exactly you are saving those files? If it's /tmp then it makes sense as flatpak has separate /tmp from host which is discarded after app close.

I have been saving them to my Downloads folder and clicked up one level I guess to my Home folder where it didn't have access. The problem was LibreOffice did not warn me it didn't actually save but I can see it in the file picker. Also that it showed seemingly non-existent files in the file picker I will take some screenshots:

1) I saved in LibreOffice, then went into the Open menu to and you can see the file that was created in a directory LibreOffice flatpak did NOT have access to

2) While still having LibreOffice open, I went in KDE Dolphin to where LibreOffice "saved" and the files do not exist

3) Close and reopen LibreOffice and you can see the files never even existed and can no longer be seen in the save or open menu within LibreOffice. I would expect the .lock file to be gone, because I closed LibreOffice. The normal file should still be there.

I understand why it happened, it is because LibreOffice does not have access to save to this location. That is fine and understandable.

The issue is, LibreOffice should have warned the user saying "Unable to save file to this location" or similar.

I also checked with ls -a in my home directory and I can guarantee you those 2 files (normal and .lock) never existed. So is this a graphical issue in the file picker? Where does LibreOffice thinks it saved this file?

Thank you for your assistance!

[Erick555]

Then I can' reproduce this. When running flatpak run --filesystem=/home/user/Downloads --nofilesystem=host org.libreoffice.LibreOffice file picker shows only my Downloads folder and I can save files there successfully.

[WineBottles]

Then I can' reproduce this. When running flatpak run --filesystem=/home/user/Downloads --nofilesystem=host org.libreoffice.LibreOffice file picker shows only my Downloads folder and I can save files there successfully.

Can you please attach a screenshot of your file picker? I wanted to compare it to mine/screenshots I provided above.

[Erick555]

I have been saving them to my Downloads folder and clicked up one level to my Home folder where it didn't have access. The problem was LibreOffice did not warn me it didn't actually save but I can see it in the file picker.

If you mean that you saved the file to /home/<something.ods> instead of /home/user/<something.ods> then it should be successfully saved (you should be able to open the file if you didn't close the app - but only with LO flatpak, not with dolphin, etc.) but after app is closed then the file will be gone because the parent /home directory isn't from host. There's no bug here.

[Erick555]

Yeah so your screenshots show what I described above - those files were actually saved but this directory was a temporary filesystem existing only in flatpak sandbox and closing app discarded it.

You may try saving the document then closing it (without closing whole app) then you should be able to re-open it until you close the app as a whole.

[WineBottles]

Yeah so your screenshots show what I described above - those files were actually saved but this directory was a temporary filesystem existing only in flatpak sandbox and closing app discarded it.

You may try saving the document then closing it (without closing whole app) then you should be able to re-open it until you close the app as a whole.

It may be a niche use case, but don't you think LibreOffice (flatpak only) should make a backup somewhere in case of this? Accidents do happen, like it did for me. If not, feel free to close this ticket. Thank you either way.

[Erick555]

Sometimes users may want to saves files in temporary filesystems (privacy, etc.) and if LO backed up those somewhere in hard drive then those users won't be pleased :smile: . Personally I don't see what LO could do if it doesn't understand what the user wanted in the end. Saving file in /tmp from non-flatpak LO then rebooting would have same effect (lost files).

[WineBottles]

Personally I don't see what LO could do if it doesn't understand what the user wanted in the end

Why not have a setting that would expose this where a user could choose if they want to have a back up created. Those who want privacy could turn it off, those that want redundancy can turn it on.

[Erick555]

Regardless if it's technically possible I bet users would learn about this setting after they lost their files not before :smile:

[WineBottles]

Regardless if it's technically possible I bet users would learn about this setting after they lost their files not before smile

This is kind of what I meant about a safety net: https://twitter.com/usebottles/status/1489307268235636737?cxt=HHwWgsC9ybvEiqspAAAA In Bottles, it will warn you if it cannot access the directory.

"Who asked for custom bottles path? 👀 #Linux Oh and don't worry about Flatpak, if you forget to give permissions it will warn you and fallback to default"

What I was trying to say earlier was it should have a fallback aka backup location where it saves if it cannot actually save to the location because it's "temp" as you mentioned.

[jasonrohrer]

This happened to us with Gnumeric (not LO), and it was INFURIATING.

I can't imagine spending hours working on something in LO, saving it, checking that it saved correctly, closing the application, and then re-opening it the next day to find that the file is GONE. With no warning? Losing a user's work with no warning cannot be the correct behavior here.

In our case, my wife has PopOS on her laptop. She needed a spreasheet, so we searched for Gnumeric in the PopShop. For whatever reason, the FlatPak version came up first, and I installed that without giving it much thought.

Then I set about helping her create a spreadsheet for her project, writing a bunch of macros, and having her enter some of the data. We saved it, quit Gnumeric, and then I was going to show her how to find the file tomorrow to work on it again. And the file was gone. WTF?

So I thought I made a mistake... maybe I hit Cancel instead of Save?

So then I re-created the spreadsheet AGAIN, and this time, I made sure it was saved. I closed it in Gnumeric and re-opened it. YES, it worked this time!

But then today, we went to look for it in Gnumeric, and it's gone again.

Worse, it was apparently not saved anywhere. Not in some temp directory.

So we have lost our work TWICE at this point. Of course, I'm going to uninstall the FlatPak version now, and install the regular apt install one.

But for a program like Gnumeric, or LO.... FlatPak seems totally useless, at least in the default configuration. Who would ever want to use these programs and NOT save their work?

Since the normal way of using an Office program is to save your work.... any FlatPak version of such programs should warn the user repeatedly that files aren't really saved. That this is a temporary session, etc.

I understand how FlatPak could be useful for a web browser or something else that doesn't save files.

But for software that usually saves files---and in the case of FlatPak, appears to save files but lies about it---the situation is ridiculous.

So yeah, this is a bug. And yeah, it should remain open! :-)

[takluyver]

This is probably only solvable by Libreoffice using the FileChooser portal to open/save files.

Flatpak deliberately sets up a temporary filesystem to run applications in, so that a compromised application (e.g. if you open a malicious document that exploits a vulnerability in LibreOffice) can't read & write arbitrary files on your system. But when the user goes to save or open a file, applications can use a 'portal' to show users their real filesystem and let them choose a file to use.

TL;DR: making a sandbox for applications that are used to running without one is hard. :disappointed:

[takluyver]

OK my comment above was overly pessimistic. Saving should work properly in most folders - this Flatpak uses --filesystem=host, which mostly disables Flatpak's sandboxing and lets Libreoffice access any file on the host system.

Of course, giving it that access does mean losing most of the security benefit of sandboxing.

[Erick555]

This issue is about saving files in paths not covered by --filesystem=host so your first comment was right - the solution is to use FileChooser portal by LO.