LiveCode Forums.

Basically I would like to know if anyone has compiled/built for the Mac App store an app that requires the user to enable Full Disk Access. And if so, what entitlements did you use?

Thanks
Mark

Our application current requires Fill Disk Access for macOS Catalina and up. There are no entitlements you can set when signing for Full Disk Access. Our solution is to place instructions at the end of our installer that provides a link to open the System Settings to the right place and tells the customer what to do. We also have the instructions prominently dsplayed on our web site for the software.

I wish there was some entitlement we could just set, but, at least as of Monterey, there is none. I have not checked to see if Apple added something for Ventura, but that still would not address Catalina through Montery.

paul@researchware.com wrote: ↑

Sun Dec 04, 2022 2:23 pm

Our application current requires Fill Disk Access for macOS Catalina and up. There are no entitlements you can set when signing for Full Disk Access. Our solution is to place instructions at the end of our installer that provides a link to open the System Settings to the right place and tells the customer what

Thanks Paul. Are you distributing through the Mac App Store or just outside the store?

Mark

Outside the store. You can see the app (HyperRESEARCH) at http://www.researchware.com/downloads.html

THis is the LC code to open system settings and jump to the permissions section:
launch url "x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles//"

paul@researchware.com wrote: ↑

Sun Dec 04, 2022 5:17 pm

Outside the store. You can see the app (HyperRESEARCH) at http://www.researchware.com/downloads.html

THis is the LC code to open system settings and jump to the permissions section:
launch url "x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles//"

Thanks. I use the same code for distribution outside the Mac App Store, but now I am trying to get this to work distributing it TO the Mac App Store and I am running into challenges I think related to sandboxing. The above code does not work (ever) if you sign it with sandboxing entitlements (which I understand are a requirement for submitting to the Mac app store). A bit frustrating actually.
PS the history of Researchware on your site was fascinating. I need to explore your app a bit further at some point.

The reason we need Full Disk Access is that we still have legacy bits of code that create folder and files that we NAME in specialFolderPath("temporary") and delete them and, as I understand it, you need to migrate to using the tempName() function. We've been gradually migrating to use a folder we create in the user's Documents folder - one of the few places left that is NOT sandboxed.

At some point (hopefully soon), we'll have all our code either using a subfolder(s) of Documents or using the tempName() function and should be able to do away with requiring "Full Disk Access"

That's a bit confusing - I thought specialFolderPath("temporary") was the system folder for temp stuff (ie can be deleted after that app closes) and that tempName() is just a random filename you can use to assign a file into that same folder? Do the two methods have different access requirements?

I don't know exactly what the issue is with Apple Sandboxing of the system temporary folder. We identified that something in our code, using specailFolderPath("temporary") for the path and then we were crating arious temp folder hierarchies and files in them in the temporary folder using our own naming conventions and doing our own deleting of these files and folders at arious points didn't work under Catalina and up and did work under Mohave and below and once we allowed Full Disk Access on Catalina and up, it worked there as well.

Livecode Ltd suggeted using tempName() function as an alternative to our own naming conventions. That seems to work too. We never had time to really did into the WHY. Sorry.

Good to know, thank for the info Paul...

marksmithhfx wrote: ↑

Mon Dec 05, 2022 6:22 pm

paul@researchware.com wrote: ↑

Sun Dec 04, 2022 5:17 pm

Outside the store. You can see the app (HyperRESEARCH) at http://www.researchware.com/downloads.html

THis is the LC code to open system settings and jump to the permissions section:
launch url "x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles//"

Thanks. I use the same code for distribution outside the Mac App Store, but now I am trying to get this to work distributing it TO the Mac App Store and I am running into challenges I think related to sandboxing. The above code does not work (ever) if you sign it with sandboxing entitlements (which I understand are a requirement for submitting to the Mac app store). A bit frustrating actually.

Code: Select all

<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.files.user-selected.read-write</key>
	<true/>
</dict>

This is just an update to indicate I have this sorted out, I think . Let me see if I can explain it clearly...

1. There is no entitlement for "Full Disk Access". Period. When Apple sandboxes your app it turns off all "entitlements" and lets you add them back one at a time. "Full disk access" is not an available entitlement. So doing full disk access is only possible outside the App Store.

2. Still, I wanted to try the App Store route so raised a Tech Support Incident with Apple. They turned out to be very helpful on a lot of fronts. First off, I did tell them I was trying to modify the Safari bookmarks file just in case that was a no-go for them. It wasn't, they provided lots of information on how to do this.

3. There are several different ways you can get access to files outside the sandbox. I am going to discuss just one here, since it was the first one I tried and it worked. You can get an entitlement (as noted in the code bit above) to gain access to "user selected" files. In my app I was just trying to access "bookmarks.plist" in the Safari folder directly and Apple prevented that. However, by pointing an Open File dialog at the /Library/Safari/ folder and having the user select the "bookmarks.plist" file, this effectively provided authorisation for the user to have access to the file.

4. It is rather short lived access however, which requires the user to select the file each time the app is launched. Minor inconvenience at this point but there is a more permanent solution in the use of something called a "security scoped bookmark" that you can set for the file. For those interested, the directions are provided here https://developer.apple.com/library/arc ... 3-CH3-SW16. It's not something I've dived into yet and it looks like a fair number of "calls" will need to be made to either API's or system level commands. Not something I know how to do at the moment, but I will look into it further as time permits.

5. Finally, you can't use the entitlement outside a sandbox, but I tried the same code to provide user access in an app built for use outside the App Store and it worked. In other words, in an app shipped outside the Mac app store, if you present the user with a dialog that selects a file, that file becomes available in the future for the user to access. So, instead of full disk access, this "user-selected-file" access works for both sandboxed and non-sandboxed apps. The only difference is, that for sandboxed apps you have to include the entitlement in the build.

Well, that is it for now. I do have further information from Apple on (1) how to determine if an app is running or open on the device (and no, it does not involve (which they do not recommend) as well as (2) "safe saving" of data to a file. There is an API for that which, in their own words...

Particularly on APFS, this sort of copy is basically atomic, so you'll
generally get a "coherent" file copy even if the app is running at the
time. Note that the safe save architecture helps ensure this by
guaranteeing the file is never accessible in an "intermediate" state.

I'll have more to say on both as I get a chance to work through them.

Oh the joy

marksmithhfx wrote: ↑

Fri Dec 23, 2022 4:47 pm

Well, that is it for now. I do have further information from Apple on (1) how to determine if an app is running or open on the device (and no, it does not involve

Code: Select all

shell("top -o rsize -ncols 2 -l 1")

(which they do not recommend) as well as (2) "safe saving" of data to a file. There is an API for that which, in their own words...

Particularly on APFS, this sort of copy is basically atomic, so you'll
generally get a "coherent" file copy even if the app is running at the
time. Note that the safe save architecture helps ensure this by
guaranteeing the file is never accessible in an "intermediate" state.

I'll have more to say on both as I get a chance to work through them.

I just realised I left this old discussion dangling without further followup. In discussion with LC it appears they do not use the "safe save" architecture so I moved on to seeing what the options where for detecting if Safari was active or not. There is an apple ObjC routine for determining if any app is running and Panos was kind enough to wrap this in a LC extension called checkSafari which returns true if Safari is running or false otherwise. This was also the subject of a LC Global 22/23 session called Problem Solving with Panos (January 2023) where he goes into more detail on how this lcb extension was created. If anyone is interested in wrapping ObjC commands in lcb I would definitely give his LCG 22/23 session a listen.

All the best,
Mark

For more on this topic see my recent post in the "Made with Livecode" forum...

https://forums.livecode.com/viewtopic.php?f=143&t=38838

Mark