It’s unfortunate that, given the over 170,000 words in current use in the English language, one has been chosen for two quite different things in macOS. The two different meanings of the term ownership are now being confused, and as a result some are recommending the wrong solutions for dealing with ownership problems. This article disambiguates them.

Contexts

One type of ownership refers to Unix-style permissions, and is the user whose UniqueID is designated as the owner of a file, folder or volume. This applies to all Macs running macOS, as well as all other systems using a similar permissions system.

The other type of ownership is only found in Apple silicon Macs, and refers to the user who has access to the Owner Identity Key (OIK) required to allow users to resign LocalPolicies for bootable systems on that Mac. I explain this in more understandable detail below, but it has nothing whatsoever to do with permissions.

Ownership in permissions

Your Mac has long user names, short user names, Bonjour names, and plenty of others, but its Unix heart just knows each user as a number, their UniqueID, with the primary admin user being given the UniqueID of 501. Every folder and file on your Mac then has an owner and a group in its permissions.

Browse permissions using Finder’s Get Info and you’ll see these expressed as names. So this preference file, from /Library/Preferences, is owned by me, but to the code that operates the permissions system, that isn’t Howard Oakley, or even hoakley, but the user with the UniqueID of 501.

Suppose that after you set your Mac up, you create a second admin user account, and remove the primary 501 account. The UniqueID for that second account could be anything upwards of 502. As an admin user, 502 can still move and remove the great majority of the files and folders that were owned by account 501, if necessary by authenticating with their password. But every single folder and file that was owned by the 501 account has now been orphaned: its owner UniqueID no longer exists.

This is the sort of problem that Migration Assistant is used to coping with, and if you were to migrate files owned by the 502 account to a new Mac where the primary admin user is still 501, they should end up on your new Mac with the correct ownership. But if you move those files over on an external drive, sooner or later you may hit a problem.

To address this, select a volume in the Finder and Get Info on it. At the foot of its Sharing & Permissions section is a checkbox reading Ignore ownership on this volume. Tick that, and macOS should pretend that the permissions there never happened. If a file is owned by 501 or 502, or anything else, then it should give you full access to it regardless of the UniqueID of your user account. It’s the Get Out of Jail card for permissions, and ideal for drives you move between different Macs, which could have users with different UniqueIDs.

Ownership and LocalPolicy

Apple silicon Macs have a secure boot process that’s configured in part by a LocalPolicy file. You can change its security settings in Startup Security Utility, in Recovery mode, and that is then saved to that boot volume’s LocalPolicy. To ensure that only fully authorised users can configure and change LocalPolicy, those Image4 files are signed, and an Owner Identity Certificate (OIC) is attached to them, and that’s where this different type of ownership comes in. This is all handled during initial setup for the internal SSD, whether the Mac is brand new or has just been fully erased and restored in DFU mode. Where it becomes more significant is when setting up another boot volume, such as a bootable external disk.

The OIC is created and signed by Apple’s Basic Attestation Authority (BAA) server in a complex series of exchanges that occur following initialisation of the default state in initial setup. This is summarised in the diagram below.

Creating and maintaining LocalPolicies requires a user to have access to the private OIK in the Secure Enclave, making that user an Owner. Apple states: “Access to the Owner Identity Key (OIK) is referred to as ‘Ownership.’ Ownership is required to allow users to resign the LocalPolicy after making policy or software changes.” Any user with access to the Volume Encryption Key for the internal storage also has access to the OIK, and has Ownership. By default, that includes all users added after FileVault encryption is enabled on a Data volume, for example.

Apple silicon Macs always start their boot process from their internal storage, even when they’re going to boot from a second operating system stored elsewhere. To be able to boot from that second OS, it requires a LocalPolicy with an OIC attached, and Ownership has to be handed off to an Install User created when that OS is installed. Creating and changing that LocalPolicy thus requires Ownership, for which the same password is required as for access to encrypted internal storage.

Handing off Ownership to the Install User is more of a problem, as users are only created once the installation is complete. To accommodate that, macOS offers to copy a user from the current boot system as the Install User, and the primary admin user, on the second OS. Apple states: “When running an Install Assistant and targeting installation for a secondary blank volume, a prompt asks the user if they’d like to copy a user from the current volume to be the first user of the second volume. If the user says yes, the ‘Install User’ which is created is, in reality, a KEK which is derived from the selected user’s password and hardware keys, which is then used to encrypt the OIK as it’s being handed to the second operating system. Then from within the second operating system Install Assistant, it prompts for that user’s password, to allow it to access the OIK in the Secure Enclave for the new operating system.”

Apple strongly recommends that this offer is accepted, as it ensures that the Install User can access the OIK, and that security is fully preserved. However, if the user decides not to copy the current user, macOS will create an Install User with a blank password.

macOS has a command tool provided for advanced users to work with boot policy and LocalPolicy for security settings on Apple silicon Macs, bputil. Although potentially a dangerous tool, used with great caution and following the guidance in its man page it can sometimes diagnose and fix problems. However, the primary tool for changing boot security on Apple silicon Macs is Startup Security Utility, and unless you really know what you are doing with bputil you shouldn’t even go near it.

Summary

• In Unix permissions on all Macs, the owner is the user whose UniqueID is designated as the owner of a file, folder or volume. If there are ownership problems, setting a volume to Ignore ownership can solve them.
• On Apple silicon Macs, the owner is a user with access to the Owner Identity Key who can change LocalPolicy for a boot volume, particularly when on an external disk. This is set during installation of that boot volume, and has absolutely nothing to do with Unix permissions.
• bputil isn’t a tool for the casual or curious. Before using it, or suggesting that anyone else might use it, read its man page and be forewarned. And remember that it has nothing whatsoever to do with permissions, but boot policy.