Bug 128233 - macOS: Can't save or open files using Finder dialog on Standard accounts
Summary: macOS: Can't save or open files using Finder dialog on Standard accounts
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.2.2 release
Hardware: x86-64 (AMD64) macOS (All)
: highest critical
Assignee: Not Assigned
URL: https://support.apple.com/guide/secur...
Whiteboard:
Keywords:
: 128690 129133 130209 130883 131017 131292 131666 132025 133044 134547 134848 135353 135481 135511 135564 136759 136981 139410 139679 140181 143531 143681 144964 147401 (view as bug list)
Depends on: 126409
Blocks: MacOS-Wishlist Desktop-Integration Save
  Show dependency treegraph
 
Reported: 2019-10-18 14:09 UTC by Alex Thurgood
Modified: 2022-07-01 10:23 UTC (History)
41 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
macOS setting hindering LibreOffice to open the file dialogue (sorry it's in German) (185.72 KB, image/png)
2022-02-09 15:08 UTC, cpohle
Details

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. ***
Comment 26 Rob 2020-08-05 17:48:38 UTC
Env: macOS 10.15.5 catalina.

Just tested with version 7.0.0.3

Situation exactly the same. Still can't "save as", "save a copy".

Don't want to change the security settings on my Mac. 
Going back to LO 6.3.6.2 where the problem does not exist (at least not on my Mac).

I am very diapointed...
Comment 27 cpohle 2020-08-05 21:24:22 UTC
(In reply to Rob from comment #26)

This still works, even with 7.0.0.3 release, and does not imply weakened macOS security settings:

>    codesign -vvv --deep --strict /Applications/LibreOffice.app

Couldn't this just be added to the langpack installer routine?
Comment 28 Telesto 2020-08-06 08:25:56 UTC
*** Bug 135481 has been marked as a duplicate of this bug. ***
Comment 29 Telesto 2020-08-07 04:54:08 UTC
*** Bug 135511 has been marked as a duplicate of this bug. ***
Comment 30 Rob 2020-08-07 12:39:01 UTC
(In reply to cpohle from comment #27)

> This still works, even with 7.0.0.3 release, and does not imply weakened
> macOS security settings:
> 
>   codesign -vvv --deep --strict /Applications/LibreOffice.app
> 
> Couldn't this just be added to the langpack installer routine?

This works for me...

Agree with cpohle that it's odd that this isn't addded to the language installer. The bproblem exists in all versions after 6.3.6.2;
Totally unclear to me why version 6.3.6.2 does work 'out of the box'.

Anyway, as the solution seems to be known, how much work is involved in implementing this?
Comment 31 Julien Nabet 2020-08-09 09:15:19 UTC
*** Bug 135564 has been marked as a duplicate of this bug. ***
Comment 32 Tim 2020-08-10 10:57:04 UTC
Same problem, unable to Save As a new document.

LibreOffice 7.0.0.3
MacOS Catalina 10.15.6
Comment 33 Rob 2020-08-10 14:18:01 UTC
(In reply to Tim from comment #32)
> Same problem, unable to Save As a new document.
> 
> LibreOffice 7.0.0.3
> MacOS Catalina 10.15.6

For me the command described in Comment #c27 solved the problem.
Comment 34 Gerry 2020-08-20 15:14:31 UTC
Same problem with
Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU-Threads: 4; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded 

on macOS Catalina 10.15.6 

Also for me this solved the problem
1. Open console
2. change the directory to the app folder
3. codesign -vvv --deep --strict LibreOffice.app
Comment 35 Peter N. Steinmetz 2020-08-26 21:06:54 UTC
Also having this problem after installing on Mac OS 10.15.6. Providing full disk access fixed the problem. 

There is another problem here in that the beachball just spins and then the focus returns to the app with no explanation. There should at least be a modal dialog explaining what happened. 

Clearly the installation process is not working as seamlessly as it should.
Comment 36 Julien Nabet 2020-09-15 07:14:14 UTC
*** Bug 136759 has been marked as a duplicate of this bug. ***
Comment 37 Rob 2020-10-29 23:11:03 UTC
Had the problem back after updating to LO 7.0.3.1
Solved by re-executing:
codesign -vvv --deep --strict /Applications/LibreOffice.app
Comment 38 Alex Thurgood 2020-12-21 09:40:43 UTC
Definitely comes under "Most Annoying" bugs - oh, wait, we don't have that any more. Every time there's a version change of LO, the whole thing raises its ugly head again.
Comment 39 Alex Thurgood 2021-01-19 11:31:17 UTC
*** Bug 139679 has been marked as a duplicate of this bug. ***
Comment 40 Alex Thurgood 2021-01-19 13:34:52 UTC
*** Bug 139410 has been marked as a duplicate of this bug. ***
Comment 41 Uwe Altmann 2021-02-05 18:03:55 UTC
I had the first occurrence of this  with LO 7.1 / MacOS 10.15.7

called from command line, "File open" immediately after starting the program throws:
uwealtmann@UwesMacBookAir ~ % /Applications/LibreOffice.app/Contents/MacOS/soffice
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
2021-02-05 18:37:10.792 soffice[1586:24735] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-05 18:37:20.957 soffice[1586:24787] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-05 18:37:31.036 soffice[1586:24787] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

"New Document" even crashes into document restore with the same output.

Funny thing is that 7.0.4 does open the Finder's file open dialog as well as a new document, but also throws:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

- but nothing else.
Comment 42 Uwe Altmann 2021-02-08 11:24:18 UTC
Funny thing which should be remarked: Opening of files shown in StartCenter by click on them works as expected.
Comment 43 Uwe Altmann 2021-02-11 10:51:44 UTC
Investigation further (Catalina 10.15.7): 
renaming user folder and doing clean install of LO 6.4.7, adding german langPack, not having Full Disk Access.
Starting from console as user, 
Create New document is OK, save works OK
Opening existing Document works, but throws five times „(pkix_CacheCert_Add: PKIX_PL_HashTable_Add for Certs skipped: entry existed“. Later doing the same these messages do not repeat.
Save this changed Document works.

Doing clean install of  LO 7.0.4, not having Full Disk Access
everything described above works OK

Doing clean install of  LO 7.1.0, not having Full Disk Access
Starting from console as user, 
Create New document is OK, save  throws 
2021-02-11 09:41:31.302 soffice[92346:1589178] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:41:41.401 soffice[92346:1589522] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:41:51.538 soffice[92346:1589629] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted

Open and save of a recently opened document from StartCenter works.

"File open" throws
2021-02-11 09:44:05.786 soffice[92346:1590496] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:44:15.944 soffice[92346:1590488] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted
2021-02-11 09:44:26.033 soffice[92346:1590674] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted

Starting from console as sudo, 
Create New document is OK, save is OK 
Open and save of a recently opened document from StartCenter works.
"File open" Opening existing Document works, save this changed Document works also.

Using LO 7.0.4 as user not having Full Disk Access
After having installed "Language toll" Extension, opening a document still works but throws 
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Comment 44 Uwe Altmann 2021-03-04 16:31:27 UTC
Updated to 11.2 "BigSur" - and 7.1/7.1.1 works like a charm.

But then: Unable even to start older versions
(to test you have to rename "user" -folder in ~/Library/Application Support/LibreOffce/4/ or it quits with some error on java version at start.)
6.2. at start brings up a Dialog window ""LibrOffice can not be opened because Apple cannot look inside the app to search for malicious software" and recommends to update. OK quits the app.
6.3. dies silently; started at command line, it just says "Application Error" and quits.
Comment 45 Brian Dobby 2021-04-07 09:16:06 UTC
I have the same problem using Draw v 7.1.2.2
Comment 46 Julien Nabet 2021-08-03 07:18:07 UTC
*** Bug 143681 has been marked as a duplicate of this bug. ***
Comment 47 Denys Prokhorov 2021-08-09 18:08:20 UTC
(In reply to Alex Thurgood from comment #0)
> 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.
> 

Repro
Created a new account with standard access rights.
-The document cannot be saved with read-only access.

If you give a standard user access to the LA Read/write application, the bug will disappear.

Additional Info:
Version: 7.3.0.0.alpha0+ / LibreOffice Community
Build ID: 246f24ebc8227345f13784d9e2f055d813f3d24f
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: ru-RU (ru_UA.UTF-8); UI: en-US
Calc: threaded

Version: 7.1.5.2 / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: ru-RU (ru_UA.UTF-8); UI: en-US
Calc: threaded
Comment 48 cpohle 2021-08-09 19:26:22 UTC
(In reply to Denys Prokhorov from comment #47)

> Repro
> Created a new account with standard access rights.
> -The document cannot be saved with read-only access.
> 
> If you give a standard user access to the LA Read/write application, the bug
> will disappear.

Would the workaround provided in comment #22 solve the bug for you?
Comment 49 Denys Prokhorov 2021-08-09 20:55:52 UTC

*** This bug has been marked as a duplicate of bug 136981 ***
Comment 50 Denys Prokhorov 2021-08-09 21:09:12 UTC
Sry missclick to duplicate Bug 136981



(In reply to cpohle from comment #48)
> (In reply to Denys Prokhorov from comment #47)
> 
> > Repro
> > Created a new account with standard access rights.
> > -The document cannot be saved with read-only access.
> > 
> > If you give a standard user access to the LA Read/write application, the bug
> > will disappear.
> 
> Would the workaround provided in comment #22 solve the bug for you?

this does not solve the problem
Comment 51 Denys Prokhorov 2021-08-09 21:15:10 UTC
*** Bug 136981 has been marked as a duplicate of this bug. ***
Comment 52 cpohle 2021-08-20 08:00:25 UTC
Still in 7.2.0.4. Would

   sudo codesign -vvv --deep --strict /Applications/LibreOffice.app

really be so difficult to add to the installer routine?
Comment 53 steve 2021-10-08 06:23:22 UTC
*** Bug 144964 has been marked as a duplicate of this bug. ***
Comment 54 Tor Lillqvist 2021-10-20 10:02:05 UTC
> adding German langPack

But adding langpacks is known to by definition break things, as it plonks stuff into the app bundle and thus makes the signature of the app bundle invalid, no? Doing that when investigating this bug only confuses things.
Comment 55 Tor Lillqvist 2021-10-20 10:08:16 UTC
So is this basically a duplicate of the old bug that says that installing langpacks the way it is done (and has always been done), separately into an already installed LibreOffice app bundle, is broken by design?
Comment 56 cpohle 2021-10-20 10:53:14 UTC
Again, not knowing the internals of how the installer works: Would it not be a feasible solution to just run the one-liner from comment 52 at the end of the installation routine to work around this "design issue"?
Comment 57 Uwe Altmann 2021-10-22 07:00:47 UTC
(In reply to Tor Lillqvist from comment #54)
> But adding langpacks is known to by definition break things, as it plonks
> stuff into the app bundle and thus makes the signature of the app bundle
> invalid, no?

The signature gets checked only at first start of the app. We changed this since years so the installer first starts and quits LO in the background (this is why it takes so long to start) and then "plonks stuff" - which worked rather good for a long time.
Comment 58 Tor Lillqvist 2021-10-25 12:00:34 UTC
> The signature gets checked only at first start of the app.

Trusting that sounds like a very ad-hoc hack. Not surprising if it doesn't work any longer. We should have made LO look for translations and other lang pack contents in another place than in the app bundle long ago. (I tried some year ago but it was much harder than expected (like most things in LO are) and I wasn't going to spend weeks on it.)
Comment 59 Alex Thurgood 2022-01-24 08:43:34 UTC
The problem is still present in current production releases.

LO doesn't seem to follow the guidelines here:

https://support.apple.com/fr-fr/guide/security/secddd1d86a6/web

The app should prompt the user each time it requires access to an as yet unauthorised folder (be that local or remote), including on installation of a new version.
Comment 60 Alex Thurgood 2022-01-24 08:43:54 UTC
*** Bug 143531 has been marked as a duplicate of this bug. ***
Comment 61 eisa01 2022-02-05 14:45:56 UTC
*** Bug 140181 has been marked as a duplicate of this bug. ***
Comment 62 eisa01 2022-02-05 15:22:20 UTC
*** Bug 137909 has been marked as a duplicate of this bug. ***
Comment 63 bugz 2022-02-06 00:09:10 UTC
(In reply to eisa01 from comment #62)
> *** Bug 137909 has been marked as a duplicate of this bug. ***

I don't think 137909 /is/ the same as 128233.  In this report, (128233), the dialog bog is described as never appearing.  In the case of 137909 the dialog box does appear, but 'freezes' for about 90 seconds.
Comment 64 Christian Lohmaier 2022-02-08 10:43:21 UTC
as mentioned the codesign call won't fix anything, as that's done by gatekeeper when the application is run first.

Previous attempts to reproduce failed here, but I'll give it another try (will update macOS on a couple machines, so will have access to the likely-to-be-more-picky setups...)
Comment 65 cpohle 2022-02-09 15:08:03 UTC
Created attachment 178171 [details]
macOS setting hindering LibreOffice to open the file dialogue (sorry it's in German)

I just discovered that under "(macOS) Settings > Security > Files and Folders", access to the Documents folder was denied for LibreOffice. Once I granted access, opening the file dialogue worked as expected.

I can't remember when this could have been happened, but maybe it's worth a look for others suffering from the same bug.
Comment 66 dhina 2022-02-15 16:12:41 UTC
*** Bug 147401 has been marked as a duplicate of this bug. ***
Comment 67 dhina 2022-02-16 16:33:16 UTC
Same issue here on any save/export/open LibreOffice documents under macOS 10.15.


Additional information:
- This issue does not happen from a fresh starting; it only happens after exporting  files to a eg PNG file that already exists.
- The dialog box does not appear, but LibreOffice is also freezing for a few second systematically.
- I still can open old documents by double-cliking on them and save them without any issues.
- On LibreOffice version 5 and 4, I had a similar issue with Export, however LibreOffice crashed systematically  after so I did not have the issue with saving/opening new file.

The trick given by @cpohle (granting acess to Libre office "(macOS) Settings > Security > Files and Folders") does not work. Actually, it was already ticked (LibreOffice asks for this access on the first use after installation, I've just checked).
Comment 68 Telesto 2022-02-16 18:35:48 UTC
(In reply to dhina from comment #67)
> Same issue here on any save/export/open LibreOffice documents under macOS
> 10.15.

See comment 34 for another solution
Comment 69 dhina 2022-02-17 10:53:13 UTC
Thanks, the command line (with "sudo" first) solved the issue mostly.

However, when I export files to a eg PNG file that already exists, it still crashes. 

Am I the only one who has this issue? If yes, that should be another bug and not related to this one.
Comment 70 dhina 2022-02-17 11:07:09 UTC
Does it make sense that on safe mode, I still have the "no Finder dialog" bug while it works without the safe mode? (after having entered the command line from comment 34)
Comment 71 dhina 2022-02-17 11:16:31 UTC
(In reply to dhina from comment #69)
> Thanks, the command line (with "sudo" first) solved the issue mostly.
> 
> However, when I export files to a eg PNG file that already exists, it still
> crashes. 
> 
> Am I the only one who has this issue? If yes, that should be another bug and
> not related to this one.

To be more specific to reproduce:

BUG 1
- restart LibreOffice
- open new Draw file
- Export > PNG > press OK
- Warning "image filter not found" > press OK
- Error saving the document Untitled 1: General Error. General input/output error

BUG 2 (variation)
- restart LibreOffice
- open new Draw file
- Add a disk shape (for instance)
- Export > PNG > press OK
- Export > PNG > press OK (with the smae name)
- "Untitled 1.png already exist. Would you like to replace it?" > Replace
- Crash: "due to an error, LibreOffice crashed"
Comment 72 Julien Nabet 2022-06-27 11:54:14 UTC
(In reply to Christian Lohmaier from comment #64)
> as mentioned the codesign call won't fix anything, as that's done by
> gatekeeper when the application is run first.
> 
> Previous attempts to reproduce failed here, but I'll give it another try
> (will update macOS on a couple machines, so will have access to the
> likely-to-be-more-picky setups...)

Christian: I don't know if you had some time to give a new try but would it be possible to add "strict" (since it may detect some pb) and replace "verbose" by "verbose=4" (to be sure to have max verbosity in all cases)?

Several people seem to indicate that using codesign with "strict" option helped. Even if they may be wrong (I know too little about macos to tell), at worst, it shouldn't worsen (could it?) the situation and perhaps some people would search another solution if this still fails?

Remark: I don't know if all the locations need to be modified
https://opengrok.libreoffice.org/search?project=core&full=codesign&defs=&refs=&path=&hist=&type=&xrd=&nn=1&si=full&si=full
Comment 73 Julien Nabet 2022-06-29 15:39:42 UTC
After some discussion with Christian following a wrong and abandoned recent patch, here are information from him (a big thanks since this tracker was really stuck!) which may help:

Hypothesis:
the prompt from macOS to grant access was not shown for some reason and did timeout and thus LibreOffice was blacklisted
Suggestions:
Reset permission for documents folder and Desktop folder respectively
-> tccutil reset SystemPolicyDocumentsFolder
and/or
-> tccutil reset SystemPolicyDesktopFolder
(beware,  without any additional parameter this will reset the permissions for all apps)

It can be done only for LibreOffice:
-> tccutil reset SystemPolicyDocumentsFolder org.libreoffice.script
-> tccutil reset SystemPolicyDesktopFolder org.libreoffice.script

it's possible to reset every privacy decision related to LibreOffice use
-> tccutil reset All org.libreoffice.script

Remarks:
- it should work as admin user or as standard user
- when running from terminal by launching /path/to/LibreOffice.app/Contents/MacOS/soffice it will be the Terminal's permissions that are applied, you'd have to use "open /path/to/LibreOffice.app" or run it from finder to have it run in its own scope


To be even more complete, you can try:
* reset permissions using the "tccutil reset All org.libreoffice.script" command mentioned above
* drag LibreOffice to a folder on disk

A) run LibreOffice without installing the languagepack first

    you get the gatekeeper prompt whether you want to run the application
    LibreOffice launches in English, as expected. Create a new file
    Hit save, file dialog defaults to Documents directory, on hitting "Save"

  → macOS should prompt and ask whether to grant LibreOffice permission to access the Documents folder
  → approve and LO should save successfully.
  → new documents should be saved to documents folder without a second prompt

    Use Save as (or just create another document, doesn't make a difference) and select the Desktop folder in the file selector, on hitting "save"

  → macOS should prompt and ask whether to grant LibreOffice permission to the Desktop folder
  → approve and LO should save successfully
  → further saves to the Desktop shouldn't trigger the prompt

    close LibreOffice and install the languagepack
    launch LibreOffice again and now shoud come up in translated form
    saving documents to desktop or documents folder shouldn't trigger a prompt and work

B) install the languagepack without launching LibreOffice first

  → after hitting "install" in the languagepack installer it should trigger launching LO and the gatekeeper should prompt asking whether you want to launch LibreOffice

    approve and the languagepack installation should continue

B.1) after languagepack installation is complete, LO shoud still run, close and restart to use it in the new locale

    creating documents and saving them should work as above, first time you try to access Documents or Desktop you get the permission prompt, subsequent ones should work without interruption.

B.2) after languagepack isntallation create a document in the still-running English LO and save

    should get the prompts as expected and save works.
    after relaunching to switch to the new UI language saving should work without additional prompts.


For those using homebrew, the mechanism is specific, bugtracker is about installing from dmg.

So if after having applied all these someone still has a problem, please provide a step by step process to reproduce this.
Let's put this one to NEEDINFO meanwhile.
Comment 74 Alex Thurgood 2022-07-01 08:21:16 UTC
(In reply to Julien Nabet from comment #73)


@Julien:

> Suggestions:
> Reset permission for documents folder and Desktop folder respectively
> -> tccutil reset SystemPolicyDocumentsFolder
> and/or
> -> tccutil reset SystemPolicyDesktopFolder
> (beware,  without any additional parameter this will reset the permissions
> for all apps)
> 

People should be aware of the downsides of playing with tccutil:

https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/

Presumably, an unprivileged user, i.e. a Standard account, will not be able to wreak any system havoc with those commands ?
Comment 75 Julien Nabet 2022-07-01 10:16:25 UTC
(In reply to Alex Thurgood from comment #74)
> (In reply to Julien Nabet from comment #73)
> 
> People should be aware of the downsides of playing with tccutil:
> 
> https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-
> protections-by-accident-and-design/
> 
> Presumably, an unprivileged user, i.e. a Standard account, will not be able
> to wreak any system havoc with those commands ?
I don't know. I suppose you must be careful when using this type of command.
Perhaps there's also a GUI allowing to do the same but with warnings just in case.

BTW, did you give it a try and did it help?
Comment 76 Christian Lohmaier 2022-07-01 10:23:58 UTC
the article mentions nothing about being able to bypass any restrictions by using the tccutil command.

Sure, if you mess with the database file directly like in the sample at the top of the article, you can do whatever, but the tccutil utility can only reset the permissions, remove any given consent or denial so that macOS will prompt again the next time the app tries to use the resource.