Full Disk Access does not make you root, and the difference is measurable

Terminal on this machine has Full Disk Access. It can read Apple’s own privacy database, the file that records which applications have been granted access to what. It cannot read the Spotlight index directory. Both refusals and permissions come back as the same two words, Permission denied, and the two situations have nothing to do with each other.

macOS runs two independent permission systems. Almost every wasted hour in this area comes from treating them as one.

Proving the grant is active

The TCC database at /Library/Application Support/com.apple.TCC/TCC.db is itself protected by TCC. A process without Full Disk Access cannot open it. So reading it is a self-demonstrating test:

sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "select count(*) from access"

52

52

Fifty-two consent records, read successfully. Full Disk Access is unambiguously granted and working.

The same shell, refused

du -sh /System/Volumes/Data/.Spotlight-V100

du: /System/Volumes/Data/.Spotlight-V100: Permission denied

Same terminal, same user, same session, seconds apart. The reason is visible in one command:

ls -ld /System/Volumes/Data/.Spotlight-V100

drwx--x---  4 root  _mds_stores  128 Mar 28  2025 /System/Volumes/Data/.Spotlight-V100

Mode 0710. The owner, root, has read, write and execute. The group _mds_stores has execute only, which permits traversing into the directory if you already know a path inside it but not listing its contents. Everyone else has nothing.

0710

My user is not root and is not in _mds_stores. The refusal is ordinary Unix file permissions, unchanged since the 1970s, and no privacy setting in System Settings affects it.

What each system actually governs

TCC

Transparency, Consent and Control gates access to categories of data: Photos, Contacts, Calendars, Mail, Messages, the Desktop and Documents folders, other applications’ container directories, the camera, the microphone, screen recording. It decides per application, based on consent you gave in a dialog or in System Settings.

TCC does not care about file modes. A file you own, with mode 0644, sitting in ~/Library/Mail, is refused to an application without the right grant despite the permissions being wide open.

Unix permissions

Ownership, group membership, and a mode per file. This decides whether a given user identity may read, write or execute a given path. It has no concept of which application is asking; only which user it is running as.

Unix permissions do not care about consent. Granting every privacy toggle in System Settings changes nothing about a mode 0710 directory owned by root.

The two failures side by side

	TCC refusal	Unix refusal
Decided by	Which app is asking	Which user is asking
Fixed by	Granting access in System Settings	sudo, or changing ownership
Affected by sudo	No	Yes
Visible in ls -l	No	Yes
Error text	Operation not permitted	Permission denied

The error text is the one useful signal, and it is not entirely reliable. TCC refusals usually surface as Operation not permitted, which corresponds to EPERM, while classic permission failures give Permission denied, corresponding to EACCES. Some tools translate or flatten these before printing, so the distinction survives more often than not rather than always.

The diagnostic that actually works

When something is refused, do not start toggling privacy settings. Look at the file first:

ls -ld /path/that/failed
id

If the mode and your identity explain the refusal, it is a Unix problem and sudo is the answer. If the mode looks like it should permit the access and it was refused anyway, it is a TCC problem and System Settings is the answer.

Applied to the Spotlight case: mode 0710, owner root, my user unprivileged. That fully explains the refusal, so no amount of Full Disk Access was ever going to change it. Running the same command under sudo succeeds immediately, because root satisfies the mode.

Why both exist

Unix permissions protect the system from users. They were designed for shared machines where the threat was one user reading another’s files.

TCC protects the user from applications. On a single-user laptop, everything you run is already you, so file modes offer no protection at all against a program you launched deciding to read your Messages database. TCC adds a second axis: not merely who is asking, but which program is asking on your behalf.

They overlap nowhere, which is why satisfying one has no effect on the other, and why a terminal can hold Apple’s most sensitive privacy database open while being turned away from a directory of search index files.

Where each system is enforced

The two gates live in different places, which is why they behave so differently.

Unix permissions are checked in the kernel’s VFS layer on every open, read and write. The check is cheap, it is based entirely on the calling process’s effective user and group against the inode’s mode bits, and it has no notion of which program is running. Changing your effective identity with sudo changes the answer immediately.

TCC is enforced through a separate daemon, tccd, and it evaluates the requesting application’s code signature against a database of consent records. It is why the prompts name an application rather than a user, and why moving or re-signing an application can invalidate a grant it previously had: the identity being checked is the signature, not the path.

# What TCC has recorded, if your terminal has Full Disk Access
sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db \
  "select service, client, auth_value from access limit 10"

service names the category, such as kTCCServiceSystemPolicyAllFiles for Full Disk Access. client is the bundle identifier. auth_value is 2 for allowed. There is a second database under ~/Library/Application Support/com.apple.TCC/ holding per-user grants, and the two are consulted together.

The failure that looks like neither

A third case exists and is worth naming because it confuses the diagnostic above. System Integrity Protection restricts writes to system locations regardless of user, including root.

csrutil status

With SIP enabled, a write to /System fails even under sudo, with Operation not permitted. The file mode may show root as having write access, and root still cannot write, because the restriction is enforced above the permission check entirely.

So the full diagnostic is three questions rather than two. Does the file mode explain it? If yes, sudo. If no, is the path inside a TCC-protected category? If yes, System Settings. If neither, and the path is under /System, it is SIP and the correct response is almost always to leave it alone.

Which applications hold which grants

Auditing this is worth doing occasionally, because Full Disk Access is a broad grant and applications accumulate it over years.

System Settings, Privacy and Security, Full Disk Access lists everything currently holding it. The list frequently contains software that needed it once for a migration and has not needed it since. Revoking is safe; anything that genuinely requires it will prompt again.

The categories worth auditing alongside it are Screen Recording, Accessibility and Input Monitoring. Accessibility in particular is the most powerful grant on the system, because it permits synthesising input events and reading window contents, which is functionally the ability to drive the machine as you.

None of those grants confers any Unix privilege at all. An application with every TCC toggle enabled still cannot read a root-owned directory with mode 0710, which is the point this article started from and the reason the two systems are worth keeping distinct in your head.

The one-line diagnostic

ls -ld /the/path/that/failed && id

If the mode and your identity explain the refusal, it is Unix and sudo resolves it. If the mode looks permissive and you were refused anyway, it is TCC and System Settings resolves it. If neither explains it and the path is under /System, it is System Integrity Protection and the correct response is to leave it alone.