darktable/inkscape/gimp: unable to access user files, when run via app bundle on big sur or monterey

[mascguy (Christopher Nielsen)]

When running these ports via their respective app bundles, user files are inaccessible on Big Sur or Monterey.

Granting "Full Disk Access" to these apps - via the macOS Security and Privacy settings - makes no discernible difference.

[mascguy (Christopher Nielsen)]

Observers: Currently testing on Big Sur and Monterey, to see what the behavior is.

Assuming there isn't an easy fix, I'll add keywords 'bigsur' and 'monterey' to ticket, for tracking purposes.

[mascguy (Christopher Nielsen)]

Per the following upstream discussion - albeit for 10.15 Catalina - it sounds like changes were made to address this. But perhaps there was a regression, or perhaps it's something related to our app bundle:

​https://github.com/darktable-org/darktable/issues/3107

[mascguy (Christopher Nielsen)]

Interestingly enough - or unsurprisingly, depending on your perspective - this is also an issue for Inkscape.

[JDLH (Jim DeLaHunt)]

I just encountered this error with inkscape @1.2_4+quartz, and inkscape-app @1.2_0 which calls the inkscape port, on macOS 12.4 Monterey. The symptom for me was that when I tried to save a file to ~/Documents or any folder within, Inkscape refused, and display an error message,

Could not read the contents of Documents. Error opening directory '/Users/myuserid/Documents': Operation not permitted. [OK]

I tried using System Preferences… Security & Privacy… Privacy… Full Disk Access to various executables: /Applications/MacPorts/Inkscape.app, /Applications/MacPorts/Inkscape.app/Contents/MacOS/Inkscape, and /opt/local/bin/inkscape. None of these were effective.

What was effective was the workaround suggested by ​​https://github.com/darktable-org/darktable/issues/3107 : 1. Ensure that, in Files and Folders, the Terminal.app has access to locations like "Documents Folder", "Network Volumes", "Desktop". 2. From the Terminal shell, run inkscape. This launches the quartz UI. I am now able to save from Inkscape to within my Documents directory.

[JDLH (Jim DeLaHunt)]

I just tried this same test with the Inkscape.app installed from the .dmg downloaded from upstream, ​https://inkscape.org/release/1.2/mac-os-x/ . The app version I got was 1.2.0 (dc2aeda), for arm64 architecture. When I tried to save a file to ~/Documents, Inkscape had the system ask me to grant it access to the Documents folder, just as is supposed to happen. So I guess this issue is related to how MacPorts packages and delivers Inkscape. We don't yet have evidence that it is a bug in the upstream code.

[mascguy (Christopher Nielsen)]

I ran some experiments in Big Sur and Monterey yesterday, specifically related to adding GateKeeper exceptions for these apps.

The original state -- before making any changes -- are as follows:

$ spctl --assess --verbose /Applications/MacPorts/darktable.app
/Applications/MacPorts/darktable.app: rejected
source=no usable signature

$ spctl --assess --verbose /Applications/MacPorts/Inkscape.app
/Applications/MacPorts/Inkscape.app: rejected
source=no usable signature

That's an expected result, as we're not signing the apps.

Then I added app-specific exceptions for these, and re-checked the assessment results:

$ sudo spctl --add --label "org.macports" /Applications/MacPorts/darktable.app
$ sudo spctl --add --label "org.macports" /Applications/MacPorts/Inkscape.app

$ spctl --assess --verbose /Applications/MacPorts/darktable.app
/Applications/MacPorts/darktable.app: accepted
source=org.macports

$ spctl --assess --verbose /Applications/MacPorts/Inkscape.app
/Applications/MacPorts/Inkscape.app: accepted
source=org.macports

However, even after adding these exceptions - and ensuring the apps are listed in the "Full Disk Access" section of the macOS Security prefpane, file/directory access is still disallowed. (Also tried rebooting afterward - which shouldn't be needed, but figured why not? - but no dice.)

[i0ntempest]

Certainly not the best practice, but disabling SIP will solve this.

[mascguy (Christopher Nielsen)]

Replying to i0ntempest:

Certainly not the best practice, but disabling SIP will solve this.

Sure, but that's something we don't want to advocate: The system protection is there for a reason - and protects users from malicious apps - so we need to solve this some other way.

[mascguy (Christopher Nielsen)]

Update: So after reading up a bit on code signing in-general - followed by greping through our existing ports - it looks like ad-hoc signing is being used for some things.

Need to test whether that's enough to solve the issue, but getting warmer!

If that's sufficient, we'll want to add that to portgroup app, to encapsulate the process.

[i0ntempest]

I do want to see signing function be added into app pg (or maybe a new pg), any unsigned app that connects to internet will cause a firewall pop up on every launch if firewall is enabled, so it would be useful for that as well. My port qBittorrent needs adhoc signing for this reason but it’s not using app pg.

[mascguy (Christopher Nielsen)]

Quick update: Thus far, my app testing has focused on accessing the standard user folders setup by macOS: Desktop, Documents, etc. All of which are now more protected from apps, in Big Sur and later.

Then it occurred to me: What if I create my own folder within the user home directory, and try accessing that? Well, sure enough, that works just fine!

And given that none of these apps appear to be formally sandboxed by GateKeeper - per the "Sandbox" column in Activity Monitor - that makes sense.

So the good news is, file access isn't blocked per se. It's only the now-protected user locations that are.

Based on further reading of various docs and articles, it sounds (?) like apps are supposed to request access to protected areas via the appropriate macOS security APIs. That would result in the user being prompted for access. But that's not happening.

So I need to dig into upstream code a bit more, and see whether such calls are in place. (And whether they're enabled by default, or require enabling via configure/build arguments.)

Regardless, slowly making progress!

[mascguy (Christopher Nielsen)]

Replying to mascguy:

Based on further reading of various docs and articles, it sounds (?) like apps are supposed to request access to protected areas via the appropriate macOS security APIs. That would result in the user being prompted for access. But that's not happening.

Stepping away from this for the past day, I had another thought: At least for GNOME-based apps, foundational libs - such as GTK or GLib2 - may be responsible for making such calls.

So I'm going to take a closer look in the GNOME space, to see if those exist. And if so, verify that they aren't disabled by a configure argument, etc.

[mascguy (Christopher Nielsen)]

Any codesign-related changes should also be tracked via issue:51504