Entitlements are settings baked into an app’s signature that enable it to do things that otherwise wouldn’t be allowed. Many let App Store apps do things their sandbox wouldn’t normally permit. Others give access to features that are controlled by privacy protection, so may be used by apps that aren’t sandboxed. A few enable apps specially approved by Apple to use features in macOS that aren’t generally available, such as working with APFS snapshots.

One way to run third-party apps in relative security is to confine them to a tightly restricted environment, a sandbox. That denies them the ability to access storage or other resources outside those dedicated to it in its sandbox. That’s too restrictive for the great majority of apps, which need to be able to open and save documents to folders such as ~/Documents, so entitlements specify which sandbox restrictions they’re allowed to break. In the case of opening and saving documents outside the sandbox, the entitlement is named com.apple.security.files.user-selected.read-write, and gives that app read and write access to files the user has selected in a standard macOS Open or Save dialog. Apple requires that all apps distributed through its App Store run in their own sandbox, so they all claim entitlements to be able to work beyond that.

Sandboxed apps all have their own entitlement to their sandbox, com.apple.security.app-sandbox, which isn’t used by apps that are notarized but not sandboxed. Whether sandboxed or not, an app might need access to the Mac’s camera, and for that it will need an entitlement named com.apple.security.device.camera.

Thus, entitlements fall into groups:

• Those that can be used by any app that wants access to controlled features, depending on whether it’s sandboxed or not.
• Those that give access to macOS features that have to be approved by Apple.
• Those that are private to Apple’s own apps and can’t be used by third-parties.

Viewing entitlements

The Finder and other macOS utilities don’t reveal whether an app runs in a sandbox, nor list its entitlements. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency.

Apparency’s Entitlements pane lists all those baked into that app’s signature. My own free Taccy also lists entitlements, but for this purpose Apparency is the better tool by far.

Apps that aren’t sandboxed, only hardened and notarized, will only have entitlements if they need to access privacy-protected features, or use restricted features in macOS. In many cases, that means they will have neither entitlements nor a provisioning profile.

com.apple.security

These give an app access to files and features that are restricted, either by the sandbox, or by privacy protection.

Sandbox controls

These are options that extend an app’s abilities beyond the sandbox, starting with the entitlement that sets the sandbox in the first place. They aren’t used by apps provided outside the App Store that are only notarized and not sandboxed. Apple provides fuller details of the sandbox here.

Examples include:

• com.apple.security.app-sandbox runs the app in a sandbox, and is standard for all sandboxed apps
• com.apple.security.files.user-selected.read-write gives read and write access to files the user has selected in a standard macOS Open or Save dialog
• com.apple.security.files.bookmarks.app-scope gives access to security-scoped bookmarks with app scope
• com.apple.security.files.bookmarks.document-scope gives access to security-scoped bookmarks with document scope
• com.apple.security.network.client allows it to open outgoing network connections
• com.apple.security.print allows it to print.

Privacy controls

These give access to information, devices and features that are controlled by the privacy features in macOS, enforced either by Location Services or by TCC. These are used by any third-party app, whether supplied through the App Store or not, and include:

• com.apple.security.personal-information.addressbook gives access to the content of the address book
• com.apple.security.personal-information.location gives access to location data from Location Services
• com.apple.security.device.camera gives access to the camera
• com.apple.security.device.microphone gives access to the microphone
• com.apple.security.automation.apple-events enables automation using AppleEvents.

These normally have a corresponding list in Privacy & Security settings.

com.apple.developer

These entitlements can only be granted by Apple, and control access to macOS features that aren’t generally available. Among the most common are:

• com.apple.developer.endpoint-security.client enables it to monitor system events for potentially malicious activity using Endpoint Security
• com.apple.developer.persistent-content-capture is required for a Virtual Network Computing (VNC) app to have persistent access to screen capture
• com.apple.developer.driverkit gives an extension permission to run as a user-space driver
• com.apple.developer.vfs.snapshot gives access to snapshot features
• com.apple.vm.networking allows virtual network interfaces without their having to escalate privileges to the root user, typically in bridged networking.

com.apple.private

These are private to Apple’s own apps, and encompass many other com.apple entitlements that aren’t documented for third-party developers. Examples include:

• com.apple.private.applemediaservices
• com.apple.private.dmd.policy
• com.apple.private.octagon
• com.apple.authkit.client.private
• com.apple.duet.activityscheduler.allow.

Some appear self-explanatory, others are opaque.

Command tools and standalone executables

Although Mach-O binaries such as command tools and daemons can be hardened and signed, thus can be notarized, they can’t have a provisioning profile embedded, so can’t have entitlements. Apple recommends working around this by wrapping them in an app-like structure, as explained here.

Entitlements for access to features controlled by privacy protection rely instead on the attribution chain to determine whether they’re entitled. Thus a command tool called by an app isn’t expected to have the entitlement, but the app calling that binary is.

Stripping signatures

Because entitlements are baked into the signature, if you were to strip the signature from an app, that would remove all its entitlements. For a sandboxed app, that might not be fatal, but for most other types of entitlement, that could render the app non-functional. Resigning the app with an ad hoc signature wouldn’t help either.

References

Apple’s Entitlements documentation
Tech Note 3125 on provisioning profiles for code signatures
If you can’t find an entitlement in any of those lists, try looking in Jonathan Levin’s database of all known entitlements for iOS and macOS, which is as comprehensive as we’re likely to get.

Before the introduction of specific protection for privacy, like all Posix-compliant operating systems, macOS had just a standard system of privileges and permissions, augmented by ACLs. Although proven in terms of security, they are too coarse to be used to protect different classes of information within the same level of privilege.

When you run an app, it naturally runs with your full user’s privileges, and has access to everything according to the permissions set on folders and files. Just as you want your privileges to give the Finder and your mail client access to all your emails and their enclosures, all other apps that you run enjoy those same privileges. But would you also want a third-party note-taking or photo-editing app to have that same level of access, even without your knowledge? Similarly, while you want FaceTime to have access to your Mac’s camera and microphone, would you be happy for any other app to access them without your being asked?

Although robust security provides a foundation for the protection of privacy, they are quite different. Your FileVault and user passwords must be protected by good security, but entries in your address book and calendar aren’t the same, and primarily a concern for privacy protection.

Consent and intent

Privacy centres on controlling access to information and devices that provide it, and there are two approaches used to give you that control, your consent and your intent. These are used throughout privacy protection in macOS.

For an app to gain access to images from your Mac’s built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that may seem tedious and even pointless at times, the decision remains yours and not the app’s or that of macOS. If the whole purpose of an app is to provide web conferencing, then its consent dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps do want camera access.

Protected folders are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one, so for that macOS may ask for your consent instead.

Command tools and helpers

Expressing intent and obtaining consent are proven methods that work for apps with a human interface. Code is run in many other ways that don’t present any interface to the user. This applies to command tools, helper apps, and similar. To apply the same principles there relies on another fundamental concept in privacy protection, the attribution chain. Although you won’t normally encounter this in the GUI, if you ever need to understand how protection works, and if you have to resort to looking at logs, you’ll find it essential.

Let’s say I have an app that builds an index of files containing references to keywords, and does so using a command tool keyindexer. For that command tool to access files in my Documents folder, it can’t rely on intent for each one, so must seek consent. As it has no interface, the only way that can be obtained is through its parent app, through the attribution chain. If I were to run that same command from Terminal, then the Terminal app would be its parent, found by macOS using its attribution chain, and that’s why many prefer to give Terminal Full Disk Access.

Universal, not extensible, permanent

One of the more common complaints about privacy protection is that it’s universal. You as a user may not keep anything private in your Documents folder, but there’s no opt-out that lets you remove that from protection. That ensures that all apps are written on the assumption that ~/Documents is a protected folder, and ensures that hostile software can’t remove protection from any folder.

Unlike permissions, you can’t extend privacy protections to other locations or features. Although that could be attractive, privacy protection is complicated enough to negotiate without it being applied to almost anything you might fancy.

Until recently, when you gave consent for an app to have access to protected locations or features, that was set until you changed it. macOS 15 Sequoia has changed that, in that you’re now reminded periodically if you have given screen recording consent for an app. This has proved problematic, with many criticisms and persistent bugs.

Informative texts and entitlements

Depending on the privacy protection, Apple can apply restrictions as to which apps can request the user for consent to access a protected resource. This is implemented in two ways: a requirement for the app to provide in its Info.plist the text to be shown to the user in the consent dialog, and an entitlement to access the protected resource that is baked into the app’s signature.

Those are far from universal across all protections, but can be inspected in the app using Apparency for verification purposes.

Apple’s reference lists

Info.plist keys
Entitlements

Articles in this series

Protected folders and places
Protected devices
Protection of location information
Protection of network devices, automation, and others

Appendix: Protection and lists

For macOS 15.3.1 Sequoia, protected resources are as follows.

Protected locations:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• Third-party cloud storage
• Removable volumes
• Network volumes via local network devices
• Time Machine backups.

Protected data:

• Calendars
• Contacts
• HomeKit
• Media & Apple Music
• Photos
• Reminders
• Focus
• Motion & Fitness.

Protected devices:

• Bluetooth
• Camera
• Input Monitoring, of mouse, trackpad, keyboard
• Local Network devices
• Microphone
• Screen & System Audio Recording
• Speech Recognition.

Protected features:

• Passkeys Access for web browsers
• Accessibility, control over the Mac
• App Management, to update or delete other apps
• Automation, control other apps, giving access to their data and documents
• Developer Tools, to run software that doesn’t meet macOS security rules
• Remote Desktop.

Possible list arguments for tccutil:

• Accessibility
• AddressBook
• All
• AppleEvents
• AudioCapture
• BluetoothAlways
• BluetoothPeripheral
• BluetoothWhileInUse
• Calendar
• Camera
• ContactsFull
• ContactsLimited
• DeveloperTool
• FileProviderDomain
• FileProviderPresence
• FinancialData
• FocusStatus
• KeyboardNetwork
• MediaLibrary
• Microphone
• Motion
• Photos
• PostEvent
• Reminders
• RemoteDesktop
• ScreenCapture
• SpeechRecognition
• SystemPolicyAllFiles
• SystemPolicyAppData
• SystemPolicyDesktopFolder
• SystemPolicyDeveloperFiles
• SystemPolicyDocumentsFolder
• SystemPolicyDownloadsFolder
• SystemPolicyNetworkVolumes
• SystemPolicyRemovableVolumes
• WebBrowserPublicKeyCredential

for use in
tccutil reset [list] [appID]
where [list] is one of the lists above, and the optional [appID] is the identifier of the app whose privacy settings are to be removed.

So far in this series explaining how you can control access to potentially sensitive features and data in macOS, I have covered the following topics:

• Gaining access to privacy-protected folders,
• Managing privacy-protected devices,
• Managing access to location information.

This article rounds those off with a brief survey of other privacy controls, including an account of the newest of them all, over local network devices.

Additional privacy controls

There are several controls over specific classes of data, including

• Calendars
• Contacts
• HomeKit
• Media & Apple Music
• Photos
• Reminders
• Focus
• Motion & Fitness.

These are normally the preserve of specialist apps that are required to seek your explicit consent, and are controlled in their own entries in Privacy & Security settings. General access to their files can be given through Full Disk Access as well, where appropriate.

There’s a final group of controls whose purposes overlap more, and as a result may appear confusing:

• Passkeys Access for Web Browsers, required if you want a third-party browser to use passkeys for authentication.
• Accessibility, allowing control over your Mac, as in Automator and AppleScript. These can be added manually.
• App Management, allowing an app to update or delete other apps, which can be added manually.
• Automation, allowing control over other apps, so giving access to the data and documents within controlled apps, and to perform actions with them, but that doesn’t include Automator itself.
• Developer Tools, required to run software locally that doesn’t meet macOS security rules such as the requirement for notarization. This is primarily for developers, and can be added manually.
• Local Network, allowing access to network devices, as described below.
• Remote Desktop, allowing access to the contents of the screen.

As with other controls, these are all managed by TCC, and their individual lists can be cleared and reset using the command
tccutil reset [list]
where [list] is one of the following:

• Accessibility
• AddressBook (for the Contacts list)
• AppleEvents (for the Automation list)
• Calendar (note the singular, for the Calendars list)
• ContactsFull
• DeveloperTool
• FocusStatus
• MediaLibrary
• Motion
• Photos
• Reminders
• RemoteDesktop
• ScreenCapture

Local network privacy

This is one of the latest, introduced in macOS Sequoia. Although common to macOS, iOS, iPadOS and visionOS, it doesn’t work the same in each. It’s explained in TN3179 of 31 October 2024, and seems likely to evolve in the future.

Many apps access remote locations outside your local network; currently there are no privacy restrictions imposed on those, but code that accesses devices inside your local network, including your router, comes within the scope of this control. Some apps that work with devices on your local network do so using code that’s automatically given local network access because it’s a Launch Daemon or running with root privileges. Together with command line tools run in Terminal or over SSH, those aren’t controlled by TCC.

Regular apps and other code that attempt to access the local network will result in the user being asked to give their consent. While apps are invited to provide the text to be used in this dialog, in an NSLocalNetworkUsageDescription in their Info.plist, at the moment that isn’t enforced as a requirement, nor is there a required entitlement. You’re thus unable to verify whether an app should be expected to request access to local network devices.

This can apply to any app that tries to list other devices on the local network, whether over wired Ethernet or Wi-Fi. Those that also access Bluetooth will additionally request that, in a separate consent dialog.

Those who know Bryan Christianson’s excellent network utility WhatRoute may already have discovered that opening it for the first time in macOS Sequoia results in a privacy consent dialog. This might appear puzzling for an app that’s all about Internet connections, but as it does look at your router and can be used within your local network, macOS includes it within this new privacy category.

For the moment, Apple doesn’t appear to provide a service name that can be used with tccutil to reset its privacy settings, and disabling them in System Settings doesn’t remove them from the list. If you really need to reset that list, you’ll have to use
tccutil reset All [appID]
with the appID of each app that has already been given access.

Finally, because of the problems with network controls in early versions of macOS Sequoia, don’t rely on local network privacy in releases prior to 15.3.

Summary: local network privacy

• Sequoia introduces consent dialogs for access to devices on the local network, including routers, via Ethernet or Wi-Fi.
• This doesn’t apply to connections made to remote locations on the Internet.
• Launch Daemons, code running with root privileges and command tools in Terminal or via SSH aren’t affected.
• Access by other apps may result in a consent dialog, and an entry in Privacy & Security settings.
• Currently tccutil can’t reset all local network privacy settings in a single command.

Macs and almost all devices assemble information about their location from local Wi-Fi networks, GPS systems (not Macs), and other sources. Access to location information in macOS is controlled in Privacy & Security settings, but unlike most of the items listed there it isn’t managed the same using TCC, but by its own service locationd in Location Services.

Tracking

In addition to those, Safari and other browsers include their own controls over tracking and location. In Safari, these are gathered in the Privacy section of its Settings, and the Location item in Websites. If you subscribe to iCloud+, you can access Private Relay in the iCloud+ section in your Apple Account.

Sharing and Find My…

Location Services are unique in that, when enabled, location data are invariably shared in iCloud, a feature you can’t control in iCloud settings. The only way to stop the sharing of locations across your iCloud-connected devices is to turn the whole service off, which is also true for iOS and iPadOS devices. Although it might seem tempting to disable Location Services altogether, that improved privacy comes at the cost of some valuable services: in particular, Find My… and Activation Lock, and many system services and apps also need Location Services to be enabled.

Settings

Location Services is the most complex of all the sections in Privacy & Security settings, and nests many of its controls deeply. This was inherited from the days of System Preferences, and hasn’t yet been redesigned to take advantage of System Settings. Above its last item, System Services, is a list of those apps over which you have direct control of their access to location data, although they can only be enabled or disabled and not removed from the list, neither can you add other apps.

Unusually, the About Location Services & Privacy button opens a window containing a mixture of help and privacy information, which is worth reading to give you better insight into what’s managed and how data is shared. It points out one important message: by giving a third-party app access to your location, that app’s vendor is in control of your location data in accordance with their terms and privacy policies, not those of Apple. If your location data is sensitive, then you shouldn’t give third-party apps access to it unless you’re confident they will protect it appropriately.

Further important controls are revealed in another window when you click on the Details… button for System Services. This lists some of the purposes for which macOS uses location data, giving you fine control over them.

The final layer in this onion is revealed when you click on the Details… button next to Significant Locations: a listing of all those locations that macOS considers to be ‘significant’. On a static Mac with mobile iOS devices, those are largely based on location data gathered from those, and are mirrored in similar lists on each device.

If you’ve never inspected these Significant Locations, you may be surprised at how much detail they contain: exact location, shown on a local street map, with time periods, over the last few months. It might be possible to reconstruct a lot of your life and activities from them. This window allows you to clear its history, in case you don’t want anyone to know where you’ve been.

Internals

Behind these is the system service locationd and its database locked away in /var/db/locationd. The official description of locationd is that it obtains geographic location data and manages access to it. When you’re prompted to give access to location data, that’s the CoreLocationAgent in action on its behalf. Apps that can ask for location data from Location Services should have the com.apple.security.personal-information.location entitlement and provide NSLocationUsageDescription information, something you can check using Apparency.

The /var/db/locationd directory contains one file that’s simple to read and holds important information, clients.plist, and various opaque data files. A sub-directory /Library has a surprising collection of scripts and cached data.

clients.plist is a standard Property List containing a dictionary of all the apps and other software that could access Location Services data. Those that are currently granted access contain the key Authorized set to <true>. In general, these should match apps and other items in the Location Services list in Privacy & Security settings, although that doesn’t apply to public or private frameworks that are included. There’s also a flag available for the key Hide suggesting that some apps or services can be given access to locations but won’t be displayed in Location Services settings.

While other privacy protections can be managed by the tccutil command tool, there’s no equivalent for Location Services. Besides, clearing its database would affect a lot of system services, including Find My… and Activation Lock, with their wider security implications.

Because of the reliance of Location Services on hardware and network features, they don’t function in Virtual Machines running on Apple silicon Macs, even though you can opt to ‘enable’ them.

Summary

• Geographic location data is derived from Wi-Fi networks and other sources, and delivered in Location Services.
• Although controls are included in Privacy & Security settings, they work differently from others, using the locationd service rather than TCC.
• Location Services are required for Find My…, Activation Lock and other macOS apps and services.
• By giving a third-party app access to your location, that app’s vendor is in control of your location data in accordance with their terms and privacy policies, not Apple’s.
• Significant Locations can give a detailed history of your movements.
• There’s no command tool to manage Location Services.

Some of the oldest privacy protections in macOS are those applied to devices such as cameras and microphones. In recent years, those have been extended to cover other types of device. This article covers the following items protected in macOS Sequoia, and listed in Privacy & Security settings:

• Bluetooth, can also be added by the user;
• Camera, requires the app to have both user text and entitlement;
• HomeKit data;
• Input Monitoring, to allow monitoring the mouse or trackpad, and keyboard, can also be added by the user;
• Local Network, to allow the app to find and communicate with network devices;
• Microphone, requires the app to have both user text and entitlement;
• Screen & System Audio Recording, to allow the app to record screen and/or audio, can also be added by the user;
• Speech Recognition, to allow access to speech recognition features.

In each case, access to the protected device is normally requested by the app, although those noted can also be added manually by the user. For an app to be allowed to access these devices, it normally has to provide text explaining why it’s doing that, and may be required to have an appropriate entitlement. In at least some cases, including camera and microphone, those are required, and an app that doesn’t provide both text and entitlement will be crashed by macOS if it tries to access that device.

In addition to those regular privacy protections, Intel laptops with T2 chips and Apple silicon laptops also feature hardware microphone disconnect, that automatically disables the microphone when their lid is closed. There is no override for that protection.

App requirements

Occasionally, when looking through the lists in Privacy & Security settings, you may come across apps that surprisingly have access to what appear to be inappropriate devices, or you may be confronted with an unexpected request for access. Don’t feel obliged to consent, but quit the app if it’s running and check its Info.plist and entitlements to establish whether this is legitimate and provides a valid reason.

This is easily accomplished using Mothers Ruin’s superb free Apparency. Open the app with that, and browse its Info Property List.

There you should see all the text it uses to populate its privacy requests. Each NS[name]UsageDescription should provide meaningful information about why the app is making that request. If you don’t see a good explanation there, then refer to the app’s documentation. Apple lists all these keys here. Note that Apple’s bundled apps don’t use text in their Info.plist and shouldn’t make privacy access requests, although its App Store apps should follow the same rules as those for third parties.

Then switch to the list of Entitlements for that app.

If the app uses cameras or microphones, you should there see respective entries for com.apple.security.device.* regardless of whether that app runs in a sandbox. You may also see additional com.apple.security.* entitlements for other protected features. Apple lists all those entitlements here.

So, for an app to make a legitimate request for access to a camera, you should see both

• NSCameraUsageDescription text in its Info.plist giving the reason for access, and
• com.apple.security.device.camera in its entitlements giving it that capability.

For access to a microphone, you should see both

• NSMicrophoneUsageDescription text in its Info.plist giving the reason for access, and
• com.apple.security.device.audio-input in its entitlements giving it that capability.

If you’re still not happy, delete the privacy setting or deny the app’s request. You can always accept the request at a later time if you wish.

Maintenance

There are times when we want to clear out some of the apps that we gave access to devices in the past. For those categories where you can remove individual settings, that’s usually the simplest course of action. But you can’t do that with camera and microphone access, for example. The only way to clear those categories is to reset them completely, then when each app requests access again to grant it to those you want to allow.

The only way to do this is in Terminal’s command line using the tccutil command tool. For example, to reset settings for microphones, enter the command
tccutil reset Microphone
and for cameras use
tccutil reset Camera

Apple doesn’t seem to document the names to be used for each category, but those worth trying according to circumstances include:

• Accessibility
• AddressBook (for the Contacts list)
• AppleEvents (for the Automation list)
• Calendar (note the singular, for the Calendars list)
• Camera
• Microphone
• Photos
• Reminders
• ScreenCapture (for the Screen Recording list)
• SystemPolicyAllFiles (for the Full Disk Access list)
• SystemPolicyDesktopFolder
• SystemPolicyDeveloperFiles (which doesn’t match any of the lists in privacy settings)
• SystemPolicyDocumentsFolder
• SystemPolicyDownloadsFolder
• SystemPolicyNetworkVolumes
• SystemPolicyRemovableVolumes
• SystemPolicySysAdminFiles (which doesn’t match any of the lists in privacy settings).

If only one or two apps are involved, then you can reset their settings with
sudo tccutil reset All com.vendor.appname
for the app with the identity com.vendor.appname, also easily discovered using Apparency.

Beyond that, a full reset can be performed using
sudo tccutil reset All
but that should remove all your consents, which would then need to be recreated one by one.

Summary

• Privacy & Security settings now control access to several types of device, including cameras and microphones.
• T2 and Apple silicon laptops have hardware microphone disconnect to disable their microphone when their lid is closed.
• Apps make requests to have access to protected devices, and some types can also be added by the user.
• Requests for access should give a meaningful reason, and some also require an entitlement.
• If in doubt, use Apparency to check their Info.plist and entitlements.
• Allow access only when you’re satisfied that it’s legitimate and for good reason.
• Device categories in Privacy & Security that can’t be changed by the user can be reset using the tccutil reset command with their category name.
• Be cautious about resetting all consents using sudo tccutil reset All as you’ll then have to recreate them all one at a time.

Last week I attempted to draw distinction between the different systems that control access to files and folders, from permissions to privacy settings. This article continues with a more detailed account of how Privacy & Security works, through the macOS Transparency, Consent and Control (TCC) system. Its settings are probably the most extensive and complicated of all System Settings, and grow worse with each new version of macOS.

Many of the controls in Privacy & Security settings refer not to folders on your Mac, but concern access to private data or sensitive hardware. The list of folders and volumes that have restricted access in macOS Sequoia is extensive:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• third-party cloud storage, if used
• removable volumes
• network volumes
• Time Machine backups.

Consent and intent

Apple’s approach to privacy is founded on two basic user controls: user consent, and user intent. These are fundamentally different, and are used in different types of protection.

For an app to gain access to its built-in camera, the app has to ask to use it, and macOS then has to ask you to give your consent to that request. Although that dialog may seem tedious and even pointless, the decision is yours and not the app’s or that of macOS. If the app is for web conferencing, then the dialog may seem pointless: after all, what’s the point of opening the app if it can’t have access to your camera? But you’ll sometimes be surprised at which apps want camera access. If you simply click through every consent dialog, then you won’t catch rogue or malicious apps.

Protected locations are different. You might want almost any app to save a document you’ve been editing in your ~/Documents folder, or on a removable volume. So when you use the File Save dialog, you expect macOS to give the app that ability, by expressing your intent. Apps may access files in other ways, in which your intent isn’t expressed: a search tool might want to look in all the files in your ~/Documents folder, but you can’t express your intent for every one. So access to protected locations may require user intent or consent.

The result for protected locations generally appears in two settings:

• individual folders are set in Files & Folders,
• system-wide access is set in Full Disk Access.

You can’t add apps directly to Files & Folders, but you can give them Full Disk Access. The difference is in how they work.

Files & Folders

Take an example, my virtualiser Viable, which doesn’t do anything privacy-related, but does provide access to some protected folders. When first installed, it has no entry in Privacy & Security. When I try to run a VM, that accesses some protected folders. As I don’t select them in a file open or save dialog, or by drag-and-drop, I don’t express my intent to access those folders. When Viable tries to do so, I’m prompted to give consent for it to access the Downloads and Desktop folders.

If I agree to those, Files & Folders is changed, adding Viable to its list, with access to those two folders enabled. If I don’t like that, or trash that app, then it’s up to me to delete its settings there. Otherwise, the next time it won’t prompt me, as I’ve already given my consent.

In the case of Files & Folders settings, you don’t have to quit the app and open it again for these changes to take effect.

Full Disk Access

Instead of doing that, you could decide to give the app Full Disk Access, which goes far beyond those two folders. In most cases, you should avoid giving everything Full Disk Access, as you could then be caught out by a rogue app. This works differently in that you have to open Privacy & Security settings, and in the Full Disk Access list, click on the + tool at the bottom left to select the app and add it.

Unlike Files & Folders, if you change its setting while the app is running, you’ll need to quit the app for the change to register and take effect.

Once that’s done, my app is listed in the Full Disk Access section. You could then disable Full Disk Access, even delete the app from here, although in both cases that needs the app to be closed and re-opened for the change to take effect.

Single files

There’s a third possibility we haven’t seen here: what if I want to use an app to edit files in a protected folder like ~/Documents? So long as I show my intent using features like file open and save dialogs, then that should go unchallenged, and you won’t be asked to give consent for the app privacy settings to be changed.

Command tools

This is fine for regular apps, but what about command tools, as they don’t have a GUI interface? Here the rules are applied through an attribution chain, based on which app called the tool to be run. In most cases, that means Terminal’s privacy settings. So if you want tools there to have access to protected folders, you’ll normally need to give consent by adding Terminal to Full Disk Access settings.

Exceptions

Unfortunately, macOS also applies some additional restrictions on locations that can be used for specific actions. For example, you can use the log collect command to save a copy of the Unified log to a logarchive for later analysis, but if you specify a path to an external disk, then the command fails, as it can’t be saved on external storage. You can, however, save the logarchive to internal storage, then move or copy it to external storage.

Summary

Rules for access to protected folders:

• If the user shows explicit intent, access is normally granted.
• If the app performs access without the user showing explicit intent to use a file in a protected folder, and the app doesn’t have Full Disk Access, then the user is prompted and that app added to the Files & Folders list to allow access to that specific folder.
• If the app needs consent for more general access, give it Full Disk Access.
• For command tools, treat Terminal as setting their access.
• Privacy controls work on top of permissions; if you or your app don’t have permissions, then privacy can’t overrule that.

Last week, in a quiet village nestling between golf courses in the Green Belt of Surrey, to the south of London, a huge void opened up in its High Street. Some of the older locals recalled there were old mine workings in the area, making it plausible that sinkhole may be due to the collapse of those abandoned mines or tunnels. What has shocked the residents of Godstone is unfortunately not uncommon, the result of failure to restore the land and what’s under it before developing on top.

Last week, after a long period of deliberate abstinence, I returned to the subject of permissions, privacy and security protections, and how they conspire to prevent us from accessing our own documents and files. In this case, there’s a warren of underground tunnels that can collapse when you’re least expecting it, although most aren’t disused but still active and poised to turn into voids of misunderstanding.

Privacy controls over locations started in macOS Mojave back in 2018, and ~/Desktop, ~/Documents, ~/Downloads, removable volumes and others were added in Catalina the following year. These have become so “transparent”, to use Apple’s well-worn euphemism, that developers have criticised them relentlessly since, and most users are still completely at sea with them, over five years later.

Apple’s Mac User Guide for Sequoia now lists 32 protection categories from Location Services to Lockdown Mode, but explains remarkably little. It passes over in silence the distinction between settings for Files & Folders and those for Full Disk Access. Presumably it leaves each individual app with the task of explaining those to the user, in the context of that app’s potential access.

This is the extent of its current explanations for users:

• Files & Folders “allow apps to access files and folders in different locations on this Mac. The listed apps have requested access.”
• Full Disk Access “allows apps to access all files on your computer, including data from other apps (for example, Mail, Messages, Safari and Home), data from Time Machine backups and certain administrative settings for all users on this Mac. To add an app, click the Add button, select the app in the list, then click Open.”

For once, information given in Apple’s Platform Security Guide is briefer, and it does come a bit closer to making that distinction, even if it avoids using the term Full Disk Access, and muddies the waters by referring instead to “full internal storage access”, which isn’t accurate.

Nowhere does Apple explain how those privacy settings interact with permissions, or any of the unexpected behaviours that we’ve become used to since Mojave. For example, some still report that an app that has been able to open a document without problems is unable to save that document, even though that file and its folder have appropriate permissions set. This has been associated with documents whose default app has been changed from that set for that document type, and undocumented extended attributes such as com.apple.macl, which is even protected by SIP to prevent the user from trying to rectify the behaviour.

For developers, there’s a long series of WWDC presentations reporting the many changes that have been made to extend privacy protection without addressing its user interface, and Apple’s Developer Forums. But if your app wants to discover whether it has been given Full Disk Access by the user, “Except in very limited circumstances, there’s no good way to:

• tell if you have the Full Disk Access privilege
• explicitly ask for the privilege.”

What if alongside its concerted effort to deliver us Apple Intelligence, it were to devote a little time to design and implement a consistent and integrated interface to permissions, privacy constraints and other limitations to what we can open and save on our Macs, and deliver it in the Finder rather than by trial and error? If Apple doesn’t address this soon, these cracks could open up like that sinkhole in Godstone.

Accessing files and folders isn’t as simple as it used to be. There was a time when, if a file was in your Home folder, you had full rights over it, and apart from those parts controlled by root, you had free roam. Now macOS plays evil tricks: you try to save a file in ~/Documents only to be told that you can’t, and even when you’ve assumed root privileges much remains out of your control. This article explains five barriers that you may have to negotiate.

Those are:

• Permissions were part of Mac OS X when it was introduced nearly 25 years ago, and provides basic controls over which users and groups can read or write items, in a system common to Unix and many other operating systems.
• Access Control Lists (ACLs) refine those permissions with more specific restrictions on access to items, and were introduced in Mac OS X 10.4 Tiger in 2005.
• Privacy controls enforced by the Transparency, Consent and Control (TCC) system have included restrictions on access to specific folders since macOS 10.14 Mojave in 2018.
• System Integrity Protection (SIP) was introduced in 2015 with El Capitan, and primarily puts system folders beyond the reach of root.
• App sandboxing is security protection that limits the files individual apps can access by imposing a sandbox as determined by their entitlements.

For any app including the Finder to have access to a file or folder, all five of those must give approval.

Permissions

The simplest and most basic controls, these can be inspected and changed in the Finder’s Get Info dialog for all accessible files and folders. They control the ability of apps and other code to read from and write to each file and folder. Normally, if you’re the named owner of a file or folder, you expect to have both read and write access, and that ensures that the apps you run with user privileges can open, edit and save changed files. There’s also the Locked checkbox that might seem obvious, although it often gets overlooked as a cause of problems when saving a file.

Some locations are particularly sensitive to errors in permissions, such as all those property lists containing settings for apps and services stored in ~/Library/Preferences. They are mostly handled by a background service cfprefsd, but if permissions have become changed so that it can’t access a property list it needs to use, all sorts of strange errors can result. In the past measures have been used to correct or repair those permissions, but those problems should now be long since past, and repairs are generally unnecessary and potentially dangerous.

ACLs

Access Control Lists, ACLs, add a more sophisticated system for enforcing more specific restrictions that cover a wide range of features. Their only common use in modern macOS is to preserve standard structures of folders in the Home folder. Regular Posix permissions don’t do that well, so a common ACL used is
group:everyone deny delete
to prevent anyone from deleting the folder it’s applied to. You should find that ACL on each named user folder and the Guest folder in /Users. Within each user folder, it’s normally applied to all the standard folders, including Desktop, Documents, Downloads, Library, Movies, Music, Pictures, Public and Sites, and on some folders within ~/Library.

The result of that ACL is that any attempt to remove that folder fails silently, so preserving the standard layout. But it doesn’t affect access given to the contents of those folders, nor can it be held responsible for errors when trying to read or write files within a protected folder. Unfortunately, the Finder’s Get Info dialog isn’t exactly forthcoming about the presence or effects of ACLs, merely stating that the user has “custom access”.

Thankfully, some GUI tools give good access to ACLs, and my favourite remains TinkerTool System, which has excellent support for them, and much more besides. It’s most valuable in displaying Effective Permissions.

Built-in tools are provided in Terminal. Show all ACLs using the command ls -le to return entries such as
drwx------@ 5 hoakley staff 160 8 Oct 12:09 Desktop
0: group:everyone deny delete
drwx------@ 81 hoakley staff 2592 17 Feb 15:42 Documents
0: group:everyone deny delete

You can add an ACL using chmod, such as
chmod +a "everyone deny delete" MyFolder

Privacy protection

macOS designates certain locations and resources as being private, and protects them using its Transparency, Consent and Control (TCC) system. Among the folders that this protects are the Desktop, Documents, Downloads, and removable storage. While access to individual folders has fine control, if you do encounter problems it’s usually simplest to add that app to the list of those with Full Disk Access, in Privacy & Security settings, in the first instance. That can leave a lot of apps with unnecessary access to private data, so you should periodically check through the list of apps with Full Disk Access to ensure they all still require it. Note that Full Disk Access can’t override permissions or ACLs.

In Sequoia, privacy-protected folders now include:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• third-party cloud storage, if used
• removable volumes
• network volumes
• Time Machine backups.

SIP and security

In principle, System Integrity Protection (SIP) should only apply to system files, but it’s also used to lock down some other components, including com.apple.macl extended attributes, which can be attached to user files. Those have been implicated in some problems in which regular user documents become locked down, and typically won’t save any changes. Although the exact role and use of this extended attribute isn’t clear, it’s generally accepted as designating an app that’s approved to edit that file, so providing document-specific privacy control.

SIP is easy to spot in the Finder’s Get Info dialog, as only the System has write access, and permissions are again described as “custom access”.

com.apple.macl extended attributes are normally protected by the same mechanism that applies SIP, so any attempt to remove them is likely to fail. One workaround for that is to pass the file through another volume, so that when it’s copied back the extended attribute is no longer protected, and can be stripped.

These problems appear most likely when apps other than that set as the default app to open a document type are used to edit files. Another approach to their solution is to select an affected document in the Finder, Get Info, set it to Open with the default app, then click on Change All… to reset all others to that default app.

Sandboxes

Sandboxing is a security feature that individual apps can opt into. As it’s a requirement of those distributed through Apple’s App Store, it’s now common in third-party software. The starting point is to restrict a sandboxed app to the folders created in its sandbox, saved in its folder in ~/Containers. As this severely limits the usefulness of most apps, it’s common for them to have entitlements that extend their ability to access files and folders beyond that basic sandbox.

As this is controlled by the entitlements system and baked into the app’s signature, it’s not something that the user has any control over. If a sandboxed app is unable to access files or folders that you need to use, contact its developer.

What can you change?

• Permissions are generally simple and easy to control. Beware of changing those in Library folders, but your documents and other files should be straightforward to manage.
• ACLs are more obscure and complex. Unless you understand what you’re doing, leave them well alone.
• Privacy controls are extensive and fraught. The only control you have here is giving apps Full Disk Access when needed. Check that list periodically to ensure you haven’t been overgenerous.
• SIP shouldn’t be tampered with unless you fully understand what you’re doing. On Apple silicon Macs disabling it reduces boot security to Permissive, with other consequences. Details of fine control using csrutil are here.
• App sandboxing isn’t within user control.