Opened 2 years ago
Last modified 20 months 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), cooljeanius (Eric Gallager) |
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 (20)
comment:1 Changed 2 years ago by mascguy (Christopher Nielsen)
comment:2 Changed 2 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|---|
Summary: | darktable: unable to access user files, when run via app bundle on monterey → darktable: 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:
comment:3 Changed 2 years ago by mascguy (Christopher Nielsen)
Description: | modified (diff) |
---|
comment:4 Changed 2 years ago by mascguy (Christopher Nielsen)
Keywords: | bigsur monterey added |
---|
comment:5 Changed 2 years ago by mascguy (Christopher Nielsen)
Interestingly enough - or unsurprisingly, depending on your perspective - this is also an issue for Inkscape.
comment:6 Changed 2 years ago by mascguy (Christopher Nielsen)
Port: | inkscape added |
---|---|
Summary: | darktable: unable to access user files, when run via app bundle on big sur or monterey → darktable/inkscape: unable to access user files, when run via app bundle on big sur or monterey |
comment:7 Changed 2 years ago by JDLH (Jim DeLaHunt)
Cc: | JDLH added |
---|
comment:8 Changed 2 years 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 2 years 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.
comment:10 Changed 2 years 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.)
comment:11 Changed 2 years 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 monterey → darktable/inkscape/gimp: unable to access user files, when run via app bundle on big sur or monterey |
comment:12 follow-up: 13 Changed 2 years ago by i0ntempest
Certainly not the best practice, but disabling SIP will solve this.
comment:13 Changed 2 years 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 2 years 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 2 years 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 2 years ago by i0ntempest
Cc: | i0ntempest added |
---|
comment:17 follow-up: 18 Changed 2 years 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 Changed 2 years 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.
comment:19 Changed 2 years ago by mascguy (Christopher Nielsen)
Cc: | RJVB added |
---|---|
Keywords: | codesign added |
Any codesign-related changes should also be tracked via issue:51504
comment:20 Changed 20 months ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
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.