Each new version of macOS has increased the complexity of launching apps, from the basics of launchd, the addition of LaunchServices, to security checks on notarization and XProtect. This article steps through the major landmarks seen when launching a notarized app that has already passed its first-run checks and is known to macOS Sequoia 15.3, on an Apple silicon Mac.

Rather than trying to provide a blow-by-blow account of what’s written in the log over the course of thousands of entries, I’ve extracted landmarks that demonstrate when each subsystem gets involved and its salient actions. These have been gleaned from several similar app launches, and are ultimately timed and taken from one complete record of one of my simpler notarized apps that has no entitlements and uses only basic AppKit features. The app hadn’t been through quarantine as it had been built and notarized on the same Mac, and had been run previously but not in that session since the previous boot. It had thus been previously registered with LaunchServices and other subsystems. The host was a Mac mini M4 Pro, so timings should be briefer than on many other Macs, it was run from the main Applications folder on the internal SSD, and AI was enabled.

LaunchServices and RunningBoard

LaunchServices has been around for many years, and handles many of the tasks exposed in the Finder, including mapping of document types to app capabilities, Recent Items and Open Recent lists, making it the backbone of app launching. RunningBoard was introduced in Catalina and has steadily assumed responsibility for managing resources used by apps, including memory and access to the GPU. Although the test app doesn’t have any of its resources managed by RunningBoard, LaunchServices launched it through RunningBoard.

RunningBoard’s first task is to create a job description, which it helpfully writes to the log as a dictionary. This is a mine of useful information, and has replaced the copious information compiled by LaunchServices in the past. This includes:

• a dictionary of Mach services
• whether Pressured Exit is enabled
• a full listing of environment variables, such as TMPDIR, SHELL, PATH
• RunningBoard properties including another TMPDIR
• whether to materialise dataless files.

Once that job description has been constructed for the app, RunningBoard tracks the app and its assertions, providing a detailed running commentary through the rest of the app’s life. LaunchServices still performs its traditional tasks, including creating an LSApplication object and sending an oapp AppleEvent to mark the opening of the app, and launchd still reports that it’s uncorking exec source upfront.

When the app is running, its preferences are loaded from the user CFPrefsD, and its pasteboard is created. Almost 0.1 second later (0.3 seconds after the start of launch) there’s a sustained flurry of log entries concerning Biome, and signs of AI involvement (Apple silicon only). The latter include a check for the availability of generative models and WritingTools. There are also entries referring to the loading of synapse observers.

LaunchServices log entries are readily accessed through its subsystem com.apple.launchservices, and RunningBoard through com.apple.runningboard.

Security and privacy

The first serious engagement in security is the verification of the app’s signature and its evaluation by Apple Mobile File Integrity (AMFI, using amfid). Shortly after that comes the standard Gatekeeper (GK) assessment, with its XProtect scan, starting less than 0.1 second after the start of launch. Immediately after the start of that scan, XProtect should report which set of data files it’s using. In Sequoia those should be at /var/protected/xprotect/XProtect.bundle/Contents/Resources/XProtect.yara. That scan took just over 0.1 second.

While XProtect is busy, syspolicyd checks the app’s notarization ticket online, through a CloudKit connection with the CKTicketStore. That’s obvious from log entries recording the network connections involved, and the complete check takes around 0.05 second. Once that and the XProtect scan are complete, syspolicyd reports the GK scan is complete, and evaluates its result.

At about the same time that the Gatekeeper checks are completing, privacy management by TCC (Transparency Consent and Control, in tccd) is starting up. Its initialisation includes establishing the Attribution Chain for any Mach-O binaries run by the app, so that TCC knows where to look for any required entitlements. Following that, TCC writes bursts of entries as different components such as the Open and Save Panel service are set up for the app.

The final phases of security initialisation come in provenance tracking, which first appeared in macOS Ventura. This may be associated with presence of the extended attribute com.apple.provenance, but details are currently sketchy.

Following syspolicy in the log is best through its subsystem com.apple.syspolicy, you can watch XProtect using com.apple.xprotect, and TCC is com.apple.TCC.

Overall

Downloadable PDF: applaunch153

Main landmarks with elapsed time in seconds:

• 0.000 Finder sendAction
• 0.023 LaunchServices, launch through RunningBoard
• 0.029 RunningBoard launch request
• 0.043 AMFI evaluate
• 0.066 Gatekeeper assessment
• 0.080 XProtect scan
• 0.085 check notarization ticket
• 0.187 TCC checks
• 0.204 launched

Previous article

Launching apps in Sonoma 14.6.1: Conclusions

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.

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.