Supported data-only export of development source files carrying `com.apple.macl`

Question

Created 1w

Replies 2

Boosts 0

Participants 2

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, a small set of ordinary development source/resource files and one project directory carry the private extended attribute com.apple.macl. We need to create a new APFS compilation-input tree, not a filesystem backup. The proposed implementation opens source and destination objects using descriptor-relative no-follow traversal and calls fcopyfile(sourceFD, destinationFD, NULL, COPYFILE_DATA), then independently verifies exact content hashes and applies an explicit destination mode and ACL policy. It does not request COPYFILE_XATTR, COPYFILE_ACL, or COPYFILE_STAT.

Is omitting com.apple.macl supported for this data-only compilation export? Could preserving it transfer stale or inappropriate access authority to the destination? Which supported API or documented postconditions should establish the destination's correct security state? Is there an Apple-recommended procedure for exporting ordinary development source content without transferring private mandatory-access metadata?

We are seeking an API and security contract, not an interpretation of the attribute's private bytes. No production paths, source code, private attribute values, credentials, datasets, or personal information are included.

Answered by DTS Engineer in 914516022

The com.apple.macl attribute is associated with macOS’s mandatory access control (MAC) subsystem, as I talk about in On File System Permissions. Whether you should copy it is a bit of a philosophical question as to the concept of what is a “file”. My only advice on that front is that you either copy it unchanged or you not copy it at all. Don’t mess around with its contents.

Oh, and I’d be remiss if I didn’t mention the <xattr_flags.h> API. This lets you query various attributes about a given extended attribute name. You can learn more about in the its man page. Notably, if you pass com.apple.macl to xattr_flags_from_name you get back a result of 0, that is, none of the flags are set.

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

Answer 1 · 1d

SouthernCrossDev26 OP

1d

This question now blocks a bounded compilation-only staging plan. We have reduced the required source closure to a frozen allowlist of 420 filesystem objects, with independent source and destination inventories and byte-hash verification. The source would remain unchanged, and no Xcode build or test would begin unless staging verification passed.

Could an Apple engineer confirm the supported destination treatment when a new object is created on a different APFS volume from source content carrying com.apple.macl: omit the attribute using data-only copying, preserve it, or use another supported API? Which destination postconditions demonstrate that access authority was neither widened nor broken?

No production copy has been performed.

Answer 2 · 1d

DTS Engineer OP

Apple

1d

Recommended

The com.apple.macl attribute is associated with macOS’s mandatory access control (MAC) subsystem, as I talk about in On File System Permissions. Whether you should copy it is a bit of a philosophical question as to the concept of what is a “file”. My only advice on that front is that you either copy it unchanged or you not copy it at all. Don’t mess around with its contents.

Oh, and I’d be remiss if I didn’t mention the <xattr_flags.h> API. This lets you query various attributes about a given extended attribute name. You can learn more about in the its man page. Notably, if you pass com.apple.macl to xattr_flags_from_name you get back a result of 0, that is, none of the flags are set.

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