Bug 128233 - macOS: Can't save or open files using Finder dialog on Standard accounts on macOS 10.15 Catalina
Summary: macOS: Can't save or open files using Finder dialog on Standard accounts on m...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 128690 129133 130209 130883 131017 131292 131666 132025 133044 134547 134848 135353 (view as bug list)
Depends on: 126409
Blocks: MacOS-Wishlist Desktop-Integration
  Show dependency treegraph
 
Reported: 2019-10-18 14:09 UTC by Alex Thurgood
Modified: 2020-08-01 14:45 UTC (History)
20 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 Alex Thurgood 2019-10-18 14:09:38 UTC
Description:
1) Create new Calc sheet as a non-administrator user of a macOS 10.15 system.
2) Enter some data.
3) Try to "Save As". The operation refuses to work. No Finder dialog is displayed.
4) The document title remains as Sans Nom 1 (Untitled 1) and can not be saved anywhere.
5) The beachball of death rotates for a while, then returns focus to the application.


For what it is worth, the ODS file contains column headers and data from a copy/paste operation from a database table.

Steps to Reproduce:
See above

Actual Results:
Saving a Calc file is impossible.

Expected Results:
Be able to save a Calc file containing the copied data to a place of the user's choosing.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Comment 1 Alex Thurgood 2019-10-18 14:10:51 UTC
See also bug 126638
Comment 2 Alex Thurgood 2019-10-18 14:25:16 UTC

*** This bug has been marked as a duplicate of bug 126638 ***
Comment 3 Xisco Faulí 2019-10-25 08:38:59 UTC Comment hidden (obsolete)
Comment 4 Alex Thurgood 2019-10-29 09:32:44 UTC
Uncoupling this from bug 126638 as I believe I have found the cause of the behaviour I reported and it appears to be different to what the OP is reporting in that bug.

I have found that the problem in my case reported here in this bug report arises when there are parallel installations of LibreOffice, with names other than just "LibreOffice".

It appears that the notarization process must lock in the name of the app bundle somewhere in the system, and if that name is changed, for example, when a user installs an "evolution" version of LO in parallel to a "stable" version, then calling any Finder dialog is blocked by the OS.

I tried this with several different functions from within LO that are supposed to call a Finder dialog :

Save as
Export
Adding a JAR archive under Preferences (for database driver configuration)

Each time, I get a beachball and no Finder dialog, effectively blocking the operation.

If I delete one of my parallel LO installations and rename the surviving one back to LibreOffice, everything seems to work as normal again.

Editing title to better reflect findings.
Comment 5 Xisco Faulí 2019-11-07 14:57:50 UTC
@Choph, this issue seems to be related to the notarization process
Comment 6 Alex Thurgood 2019-11-21 10:02:03 UTC
No doubt adding the application bundle to the list of "Full Disk Access" apps might solve this.

The installation should take of this, though, and it doesn't. Asking a user to specifically manually bypass the security model to allow whole disk access is bit of a problem.
Comment 7 Ahmad Haris 2019-11-26 13:28:31 UTC
I set to NEW
Comment 8 Alex Thurgood 2019-12-02 08:42:51 UTC
*** Bug 129133 has been marked as a duplicate of this bug. ***
Comment 9 Paul Oranje 2019-12-03 22:57:15 UTC
(In reply to Alex Thurgood from comment #6)
> No doubt adding the application bundle to the list of "Full Disk Access"
> apps might solve this.
> 
> The installation should take of this, though, and it doesn't. Asking a user
> to specifically manually bypass the security model to allow whole disk
> access is bit of a problem.

On Catalina:

When LO is installed (in my case with Homebrew) "Save" and "Save as" dialogs run fine, but once the LO app is **changed** by running a language pack (installer), these (Finder) dialogs cannot be invoked any more.

By adding the (changed) LO app to the list of apps that are allowed "Full Disk Access", then the save dialogs can be invoked again.

In short: your suggestion is correct and relevant for the installation of language packs, because that installation should also refresh any relevant permission for the (changed) LO app.
Comment 10 Paul Oranje 2019-12-03 23:16:42 UTC
The part "with parallel LO installations" could very well be dropped from the summary.
Comment 11 Alex Thurgood 2020-03-02 08:13:14 UTC
*** Bug 131017 has been marked as a duplicate of this bug. ***
Comment 12 eisa01 2020-04-10 09:46:31 UTC
*** Bug 130883 has been marked as a duplicate of this bug. ***
Comment 13 eisa01 2020-04-10 09:47:32 UTC
*** Bug 131666 has been marked as a duplicate of this bug. ***
Comment 14 eisa01 2020-04-10 09:48:28 UTC
*** Bug 128690 has been marked as a duplicate of this bug. ***
Comment 15 eisa01 2020-04-10 09:55:38 UTC
*** Bug 130209 has been marked as a duplicate of this bug. ***
Comment 16 eisa01 2020-04-10 14:56:58 UTC
So I installed Catalina on a fresh drive to investigate this issue.

As far as I can tell, this may be related to the code signing that is broken.

Granting "Full Disk Access" makes the issue go away
Comment 17 eisa01 2020-04-10 15:12:32 UTC
This may be hard to replicate, as now my copy of LO on a standard account is working without Full Disk Access. It may be because I manually verified using the command line to check the output from bug 126409, I don't know.

It's best done on a completely fresh install on a new Standard user to mimic what a new user would encounter

Version: 6.4.2.2
Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 4; OS: Mac OS X 10.15.4; UI render: default; VCL: osx; 
Locale: en-US (en_NO.UTF-8); UI-Language: en-US
Calc: threaded
Comment 18 Alex Thurgood 2020-05-13 07:59:29 UTC
Reproduced with

Version: 7.0.0.0.alpha1
Build ID: 6a03b2a54143a9bc0c6d4c7f1...
CPU threads: 8; OS: Mac OS X 10.15.4; UI render: GL; VCL: osx; 
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded
Comment 19 Alex Thurgood 2020-05-15 07:15:12 UTC
*** Bug 133044 has been marked as a duplicate of this bug. ***
Comment 20 Alex Thurgood 2020-06-02 08:48:49 UTC
*** Bug 131292 has been marked as a duplicate of this bug. ***
Comment 21 steve -_- 2020-07-22 13:53:34 UTC
*** Bug 132025 has been marked as a duplicate of this bug. ***
Comment 22 cpohle 2020-07-22 21:52:49 UTC
As already suggested in duplicate Bug 132025: 

Maybe running

   codesign -vvv --deep --strict LibreOffice.app

automatically by the language pack installer would solve the problem?
Comment 23 Timur 2020-07-23 08:17:44 UTC
*** Bug 134547 has been marked as a duplicate of this bug. ***
Comment 24 Julien Nabet 2020-08-01 07:14:23 UTC
*** Bug 135353 has been marked as a duplicate of this bug. ***
Comment 25 Telesto 2020-08-01 14:45:05 UTC
*** Bug 134848 has been marked as a duplicate of this bug. ***