As some of us have discovered, 10.14 GM <> 10.14 Developer betas. The new “Full Disk Access” idiocy is having a negative affect on tools that need to do things that Apple have now deemed “suspicious”. Even the root user can’t access things like a user’s Mail folder.
I’m aware of the “Security and Privacy” -> “Full Disk Access” settings, but it seems that setting only supports bundled apps and not console helper apps.
Are any of you that live in the macOS API/SDK more deeply than me aware of APIs that allow us to sort this in our apps without user intervention?
But the security is beyond stupid. I can get a references to a folder in the Mail folder. But counting items always gives me a fat 0.
[code]dim f as FolderItem = GetFolderItem("/Users/beatrixwillius/Library/Mail/V6/18EA0B79-2DA3-44E4-8D24-346258E3EE24", FolderItem.PathTypeShell)
if f = Nil then Return
dim i as Integer = f.Count
MsgBox str(i)[/code]
So how does my competitors handle this? Shell? AppleScript?
@Tim Parnell: yes, I built a version of the app and gave that full disk access.
@Dave S: yes, the folder is an example.
AppleScript in Script Editor:
tell application "Finder"
set file_list to name of every file of entire contents of (choose folder with prompt "Please select directory.")
end tell
Gives
[quote]error “Finder hat einen Fehler erhalten: every file of folder “81763DE9-295A-46D6-A41B-90C7FF0FD522” of folder “Archive.mbox” of folder “18EA0B79-2DA3-44E4-8D24-346258E3EE24” of folder “V6” of folder “Mail” of folder “Library” of folder “beatrixwillius” of folder “Users” of startup disk kann nicht gelesen werden.” number -1728 from every file of folder “81763DE9-295A-46D6-A41B-90C7FF0FD522” of folder “Archive.mbox” of folder “18EA0B79-2DA3-44E4-8D24-346258E3EE24” of folder “V6” of folder “Mail” of folder “Library” of folder “beatrixwillius” of folder “Users” of startup disk
Kann nicht gelesen werden = can’t be read[/quote]
Shellscript in Xojo:
[code]dim s as string = “ls /Users/beatrixwillius/Library/Mail/V6/18EA0B79-2DA3-44E4-8D24-346258E3EE24/Archive.mbox”
dim theShell as new Shell
theShell.Execute s
if theShell.ErrorCode <> 0 then Return
So, I’m not blind and didn’t miss some big SDK documentation location for this.
I know that I can enable it for a bundled app by setting the whitelist entry for the bundled parent app. My issue is that there is no way to do this for a console, non-bundled app.
I’ve filed a RADAR on this requesting support for non-bundled apps and was very polite and kept my iOS commentary at bay, but we know how Apple is about their security baby.
[quote=426554:@Beatrix Willius]@Tim Parnell: yes, I built a version of the app and gave that full disk access.
@Dave S: yes, the folder is an example.
AppleScript in Script Editor:
tell application "Finder"
set file_list to name of every file of entire contents of (choose folder with prompt "Please select directory.")
end tell
Gives
Shellscript in Xojo:
[code]dim s as string = “ls /Users/beatrixwillius/Library/Mail/V6/18EA0B79-2DA3-44E4-8D24-346258E3EE24/Archive.mbox”
dim theShell as new Shell
theShell.Execute s
if theShell.ErrorCode <> 0 then Return
msgbox theShell.Result[/code]
Makes an IOException 1.[/quote]
What does:
ls -al@ /Users/beatrixwillius/Library/Mail/V6/18EA0B79-2DA3-44E4-8D24-346258E3EE24
IDK if this will help, but to get console apps to access files from a Sandboxed application, you have to use IPC and pass a non-secure Security-Scoped Bodgemark while the main application holds open a Secure Security-Scoped Bodgemark. Once the console application has accessed the file, the main app can then safely relinquish access on the Security-Scoped Bodgemark, and then the console app can still access the file.
Or you just move the file to a location the console application can access.
Does the app need to be signed when accessing Mail data? This is just my testing laptop here where I don’t do any signing. That would make debugging truly foobared.
While I havent had to tackle this particular problem I can tell you that with the AppleScript permissions you have to re-allow the specific access in the security preferences whenever you update the app. The problem is that it doesnt actually disable it, it appears that it is still granted permission but it wont actually allow them until you go into that manually, uncheck and re-check the checkbox. It doesnt do this all the time, but enough that Ive had to tell users about it as a debugging tool. The new security stuff is horrible. Not that the idea is horrible, but the implementation is horrible and buggy and inconsistent and causing me all sorts of headaches too.
Since whitelisting adds a plist entry to a bundled app, you would need to run paused, re-add the current debug build to the whitelist, and then launch.
I’m not sure why your code signing step takes so long. I use an IDE script as the last part of my build steps and it adds maybe 10 seconds to my largest project.
I believe that this entry is invalid for a non-codesigned app bundle … in other words, the app must be code signed in order for that entry to be added.
Surprisingly, I received a follow up from Apple on the lack of non-bundled binary support in the Full Disk Access whitelist.
Unsurprisingly, their answer was a now standard “That’s the way it’s supposed to work.” They even went so far as to recommend enabling FDA for Terminal.App - which is hilarious since that obviates the FDA protocol completely.
I’ve now used a development incident to ask for a way to solve this at my end - <cues Jeopardy “Final Jeopardy” theme…>