sandbox entitlement with no sandbox

I am trying to understand better entitlements. When reading Apple's documentation, my understanding was that sandbox entitlements like com.apple.security.device.camera were useful when the app was sandbox, by allowing this specific capability.

If that understanding is correct, then I am confused when looking at the entitlements of the app visual studio code :

<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
    <key>com.apple.security.cs.disable-library-validation</key>
    <true/>
    <key>com.apple.security.device.audio-input</key>
    <true/>
    <key>com.apple.security.device.camera</key>
    <true/>
    <key>com.apple.security.automation.apple-events</key>
    <true/>
</dict>

Indeed, this app is NOT sandboxed (it does not have the com.apple.security.app-sandbox entitlement), and yet it has these sandbox entitlements that give permission.

Are these entitlements effectively useless in that case? Or is my understanding off?

In addition, if an app has a certain entitlements, does it mean the app can use that capability and it will not prompt the user? Or does the entitlement simply allow the app to prompt the user for permission?

As I mentioned on your other thread, you need to understand the difference between the App Sandbox and the hardened runtime.

With regards com.apple.security.device.camera specifically, this applies to both (which was news to me!). All the other entitlements you mentioned are for the hardened runtime, not the App Sandbox.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Ah, that makes sense. Thank you, I was missing that piece.

sandbox entitlement with no sandbox
 
 
Q