Comment by mike_hearn

macOS already has a way to do that if you're a developer, but it's weirdly both obvious and non-obvious enough that people don't seem to use it: just compile a simple program that executes other programs, and then sign it with the officially supported sandbox entitlements. You will need a supervisor program that starts up the sandboxed sub-process and grants it access to the needed files via the official bookmarks API (that's what it's called):

https://developer.apple.com/documentation/security/accessing...

Now you're wondering why this isn't built in to the OS. But it is! Apps from the Mac App Store are always sandboxed. Just get your apps from there, and now you know what permissions they need because the store can tell you, as can the Settings app. You can even toggle permissions on and off via Settings.

macOS has the best sandbox of any desktop OS by far. Seatbelt isn't actually deprecated and never has been. Marking it as such seems to be just a way to warn developers off trying to use it directly. Nonetheless, it's not going anywhere: Chrome's sandbox relies on it heavily and if Apple tried to remove it or even just break backwards compatibility with it they'd break Chrome, and if not done in a coordinated manner that'd open up a lot of nasty lawsuit potential and corporate relationship problems.

The reason Apple don't want you using Seatbelt directly is that you have to be an expert in macOS internals to use it correctly ... and those internals change with every release. I reported a vulnerability to a well known company just a couple of weeks ago that involved them using Seatbelt wrong! Apple's entitlements wrap up a common set of use cases under a stable API and it's then on Apple to keep them working correctly as the internals move around.