Opened 4 months ago

Last modified 5 weeks ago

#65302 assigned defect

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

Reported by: mascguy (Christopher Nielsen) Owned by: mascguy (Christopher Nielsen)
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: app-bundle, bigsur, monterey, codesign Cc: gpagnon, JDLH (Jim DeLaHunt), i0ntempest, RJVB (René Bertin)
Port: darktable inkscape gimp

Description (last modified by 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.

Change History (19)

comment:1 Changed 4 months ago by 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.

comment:2 Changed 4 months ago by mascguy (Christopher Nielsen)

Description: modified (diff)
Summary: darktable: unable to access user files, when run via app bundle on montereydarktable: unable to access user files, when run via app bundle on big sur or monterey

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

comment:3 Changed 4 months ago by mascguy (Christopher Nielsen)

Description: modified (diff)

comment:4 Changed 4 months ago by mascguy (Christopher Nielsen)

Keywords: bigsur monterey added

comment:5 Changed 4 months ago by mascguy (Christopher Nielsen)

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

comment:6 Changed 4 months ago by mascguy (Christopher Nielsen)

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

comment:7 Changed 3 months ago by JDLH (Jim DeLaHunt)

Cc: JDLH added

comment:8 Changed 3 months ago by 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.

comment:9 Changed 3 months ago by 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.

Last edited 3 months ago by JDLH (Jim DeLaHunt) (previous) (diff)

comment:10 Changed 3 months ago by 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 -- is 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.)

Last edited 3 months ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:11 Changed 3 months ago by mascguy (Christopher Nielsen)

Description: modified (diff)
Port: gimp added
Summary: darktable/inkscape: unable to access user files, when run via app bundle on big sur or montereydarktable/inkscape/gimp: unable to access user files, when run via app bundle on big sur or monterey

comment:12 Changed 3 months ago by i0ntempest

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

comment:13 in reply to:  12 Changed 3 months ago by 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.

comment:14 Changed 3 months ago by 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.

comment:15 Changed 3 months ago by 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.

comment:16 Changed 3 months ago by i0ntempest

Cc: i0ntempest added

comment:17 Changed 2 months ago by 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!

comment:18 in reply to:  17 Changed 2 months ago by 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.

Last edited 2 months ago by mascguy (Christopher Nielsen) (previous) (diff)

comment:19 Changed 5 weeks ago by mascguy (Christopher Nielsen)

Cc: RJVB added
Keywords: codesign added

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

Note: See TracTickets for help on using tickets.