Explore the core architecture of the operating system, including the kernel, memory management, and process scheduling.

Posts under Core OS subtopic

Post

Replies

Boosts

Views

Activity

Core OS Resources
General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"
0
0
2.2k
Aug ’25
macOS: How to reliably verify the absence of an extended ACL using a file descriptor?
We are implementing a fail-closed security check for a directory opened through a file descriptor on macOS. We need to reliably distinguish between: No extended ACL is present. An extended ACL is present but contains zero entries. ACL retrieval failed or is unsupported. Observed behavior For an existing directory with mode 0700: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. acl_get_file(path, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. fstat() and lstat() agree on the device and inode. The directory exists and can be opened successfully. ls -ldeO@ displays no extended ACL entries. We reviewed Apple's open-source implementations of acl_get_fd_np() and filesec_get_property(). We understand that ENOENT can result from an unavailable FILESEC_ACL property, rather than a missing filesystem object. We also understand that XNU distinguishes an empty ACL from KAUTH_FILESEC_NOACL. Question Is there a publicly supported, file-descriptor-based API with documented postconditions that can reliably prove the absence of an extended ACL, while distinguishing it from an empty ACL and an ACL retrieval failure? Specifically: Can fstatx_np() and filesec_get_property() provide this distinction? Can fgetattrlist() with ATTR_CMN_EXTENDED_SECURITY and ATTR_CMN_RETURNED_ATTRS reliably establish ACL absence? What additional filesystem capability checks or return-value checks are required? If no public API provides this guarantee, is that a documented limitation? For security reasons, our implementation rejects the object whenever ACL absence cannot be established reliably. We would appreciate clarification of the supported API contract and its limitations. Thank you.
1
0
39
59m
macOS 27/APFS: Supported ACL Absence Verification When acl_get_fd_np Returns ENOENT
Subject: Supported fail-closed ACL absence verification on macOS 27.0.1 / APFS Environment: macOS 27.0.1, build 26A434; APFS; installed macOS 27.0 SDK. We need a supported, documented way to determine whether an existing filesystem object has no effective ACL entries, while rejecting genuine retrieval failures and unsupported or unavailable ACL evidence. We are seeking clarification of the public interface contract, not alleging an Apple defect. For existing directory and regular-file fixtures, pathname metadata and descriptor metadata identify the same object. Errno is cleared immediately before each native call and captured immediately afterward. ACL retrieval uses ACL_TYPE_EXTENDED: acl_get_file(path, ACL_TYPE_EXTENDED) acl_get_fd_np(fd, ACL_TYPE_EXTENDED) On fresh objects, both return NULL with ENOENT. Explicit one-entry fixture ACLs are retrieved successfully. Explicit zero-entry fixture ACLs can also yield NULL/ENOENT, while attribute queries return a serialized zero-entry ACL. The attribute queries use getattrlist() and descriptor-bound fgetattrlist(), requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_NOFOLLOW | FSOPT_REPORT_FULLSIZE and WITHOUT FSOPT_PACK_INVAL_ATTRS. Buffer lengths, variable-reference bounds and returned-attribute validity are checked. For the existing directories of interest, both calls succeed but omit the ATTR_CMN_EXTENDED_SECURITY returned bit. Explicit populated and zero-entry fixture records do set the bit. APFS reports valid VOL_CAP_INT_EXTENDED_SECURITY support; we do not assume that volume capability proves per-object ACL availability. On macOS 27.0.1, build 26A434, using APFS, which supported interface and documented conditions allow software to distinguish an absent ACL from unavailable or unsupported ACL evidence when descriptor-bound attribute queries succeed but omit ATTR_CMN_EXTENDED_SECURITY and native ACL getters return ENOENT for an existing object? Please clarify: Whether ENOENT has a supported ACL-absence interpretation, and under exactly which checked conditions. Whether an omitted extended-security attribute can establish ACL absence, rather than unavailable or unsupported evidence. How explicit zero-entry ACLs differ from absent ACL records through supported interfaces. How KAUTH_FILESEC_NOACL should be interpreted through supported APIs. How genuine retrieval failures, including permission, I/O, allocation and unsupported-operation errors, must remain distinguishable. Whether a supported descriptor-bound verification method exists that preserves fail-closed security checks and object identity binding; please identify its guarantees and limitations regarding pathname/ancestor changes and later operations. Whether relevant behavior is specific to this macOS/APFS version. Please identify the applicable public documentation or supported verification sequence. We do not want to modify permissions, synthesize ACLs on target objects, treat invalid-attribute defaults as real evidence, or accept ambiguous omission/ENOENT as success. Existing ownership, mode and confinement checks must remain separate mandatory checks. If no public API can make this distinction reliably, please state that limitation.
3
0
291
1h
How can a macOS application establish that an open APFS file has no extended ACL?
On macOS 26.5.2 (build 25F84), which documented API and return conditions, if any, establish that a regular file on APFS has no extended access control list (ACL), using an already-open file descriptor? We tested three disposable regular files on an APFS volume reporting ACL support. For each file, we opened a read-only file descriptor and called: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY Before and after inspection, fstat() confirmed stable device, inode, mode, and change timestamp. Observed results: 1. Newly created file, no ACL explicitly assigned acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() succeeded but omitted ATTR_CMN_EXTENDED_SECURITY from the returned attribute mask. FSOPT_PACK_INVAL_ATTRS also left that bit clear. 2. File with an explicitly assigned empty ACL acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() returned the extended-security attribute with an ACL entry count of zero. 3. File with one explicit ACL entry acl_get_fd_np() returned a non-null ACL. fgetattrlist() returned the extended-security attribute with an ACL entry count of one. Apple's published XNU attribute-packing implementation appears to use the same omission branch when ACL metadata is unsupported or when the ACL pointer is null. My question: Is there a supported descriptor-based API sequence that reliably distinguishes: Genuine absence of an extended ACL Unavailable or unsupported per-file ACL metadata An ACL retrieval failure If so, which API, capability checks, return values, attribute bits, or error conditions should a caller rely on? Are there relevant APFS or macOS version limitations? If the public API cannot establish ACL absence unambiguously in this situation, confirmation of that limitation would also be helpful. Thank you for your guidance.
1
0
29
1h
Import resulting certificate to associate with private key
On macOS I am creating a public/private key pair (ECDSA 256), will be secure enclave in the long run, just trying to baseline some functionality right now using file store (currently running in a system daemon). I can sign data using the private key with no problem, and export the public key. However, after generating a cert chain via CSR externally, I’m trying to figure out the proper incantation to import that cert/chain and have it recognized as matching the existing private key, but so far I can’t figure out the correct attributes to get it to pair up. Do you have any sample code that might have the right SecAddItem (or such) calls that would make this work as expected?
9
0
2.1k
5h
Installing a macOS guest onto an external USB disk with Virtualization.framework (sandboxed app)
Hello, We develop a sandboxed Mac App Store app that runs virtual machines with Virtualization.framework on Apple silicon (macOS 27). Users want to install a macOS guest onto an external USB disk and start the VM from it, so they can keep a VM on portable storage or on a disk larger than the Mac's internal drive. What we tried USB passthrough: we attach the disk before the VM starts, with VZUSBPassthroughDeviceConfiguration (from an AAUSBAccessory) on a VZXHCIControllerConfiguration. Linux guests install onto the disk and boot from it without problems. For a macOS guest, VZMacOSInstaller fails to start when the USB disk is the only storage: As we understand it, a macOS VM can only start from its own storage devices, never from a USB device, so even a successful install would not boot. VZDiskBlockDeviceStorageDeviceAttachment: this needs an open file handle to /dev/diskN. That requires admin rights, which a sandboxed app can't obtain, so we can't use it in our App Store app. Questions Is there a supported way to install a macOS guest onto an external USB disk and start the VM from it? Is there a sandbox-compatible way to get a VZDiskBlockDeviceStorageDeviceAttachment for an external disk, for example after user consent, similar to how AccessoryAccess grants USB devices? If neither is possible today, is support for this planned, or is there a recommended alternative? Thank you for any guidance.
5
0
87
6h
Using tcsetattr on stdin in sandboxed CLI app does not work due ioctl restriction
Our (sandboxed, distributed through the Mac App Store) app can optionally run as a CLI tool, to allow users to use it in scripts and other automation contexts. One of the usecases involves being a wrapper for the ssh command, but the ssh binary is not able to enable raw mode for stdin due to a sandbox violation (bug report). As a reduced example, I've created https://github.com/mihaip/sandboxed-cli-test, which has a minimal C program that uses tcsetattr to set attributes on stdin. That fails, and sandboxd logs to the console Sandbox: SandboxedCLI(30110) deny(1) file-ioctl /dev/ttys012. If I disable sandboxing on the binary then it works as expected. Looking through the sandbox profiles on /System/Library/Sandbox/Profiles, I'm not seeing cases where file-ioctl is enabled on /dev/tty. Are we out of luck, or is there a workaround?
1
5
1.4k
9h
Supported provenance handling when copying a verified helper
What supported public contract should software use for com.apple.provenance when copying an exact expected helper binary into a new, private owner-controlled working directory for separately authorized later use? We want to leave originals unchanged, preserve security protections, and avoid removing, decoding or reconstructing opaque Apple attribute values. Program-byte identity, permissions/custody and code validation are separate from this metadata question; an attribute name or copy success is not treated as a trust decision. Public APIs reviewed: fcopyfile with independent DATA/XATTR selection, and xattr_flags_from_name with xattr_intent_with_flags for COPY intent. A bounded public-constant probe returned zero property flags and the default preserve result for both com.apple.provenance and an invented unknown name. We therefore do not interpret that default as proof of recognition or an exemption. Could you clarify: Which supported metadata postconditions apply to this specific copy use? Is source/destination raw-value equality an appropriate invariant for this opaque attribute, or may the OS legitimately create different destination metadata while preserving the intended security behavior? Which public properties or APIs can establish the intended destination state without parsing/removing private values or weakening OS protections? The xattr manual's named-wrapper return sentence appears inconsistent with its flags-based description/example. What is the supported return-polarity contract, and is using the flags-based function the intended interpretation? This asks for supported semantics, not a bypass or private value format. No paths, binaries, source, attribute values, keys, account data or logs are attached. Public references: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fcopyfile.3.html https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_name_with_flags.3 https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_flags.h
1
0
81
12h
macOS/APFS: interpreting acl_get_fd_np ENOENT and omitted extended-security attributes
Apple Support directed me to the Developer Forums for this API-contract question. I am implementing conservative, read-only ACL classification for existing files and directories. I need to distinguish an absent ACL from unavailable or incomplete ACL information. Ambiguous results are currently rejected. The measurements below were taken on macOS 26.5, build 25F71, Apple Silicon (arm64), on APFS. Method I tested eight newly created objects: a regular file and a directory in each of four preparation states: Fresh: no ACL setter, deletion or normalization was performed. Explicit-empty ACL preparation. One DENY entry. One ALLOW entry. “Fresh” describes preparation only; I am not assuming it independently proves ACL absence. Each object remained open through preparation and two observations using the same file descriptor. Each observation performed: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_REPORT_FULLSIZE and without FSOPT_PACK_INVAL_ATTRS. Errno was cleared immediately before each query and captured immediately afterward. Descriptor/path identity and metadata stability were checked. Returned lengths, attribute bitmaps and applicable reference/payload bounds were validated. Observations Results matched between the two observations and between regular files and directories: Preparationacl_get_fd_np resultfgetattrlist returnEXTENDED_SECURITY returnedReturned filesec ACE countAttribute-buffer lengthFreshNULL, errno ENOENT0NoN/A32 bytesExplicit-emptyNULL, errno ENOENT0Yes076 bytesOne DENY entryNon-NULL, errno 00Yes1100 bytesOne ALLOW entryNon-NULL, errno 00Yes1100 bytesWhen the getter returned NULL, ACL validation and enumeration were not performed; their results are N/A, not measured zeros or an empty entry list. When EXTENDED_SECURITY was omitted, its payload fields were unavailable. I did not interpret default buffer values as returned ACL information. An actually returned zero-entry record is distinct from omission. No NOACL sentinel was observed in this experiment. Question For a valid descriptor referring to an existing APFS object, what is the supported interpretation of: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returning NULL with ENOENT; and fgetattrlist() succeeding while omitting ATTR_CMN_EXTENDED_SECURITY from the returned attribute bitmap? In particular: Can this combination establish ACL absence under documented conditions, or must it remain classified as unavailable/ambiguous information? How should the observed NULL/ENOENT with an actually returned zero-entry ACL record be interpreted? If these results cannot establish absence, which supported read-only, descriptor-based API or verification sequence should be used? What guarantees and limitations apply regarding macOS versions, filesystem support and genuine retrieval failures? I reviewed the acl_get(3) documentation but could not find a clear explanation of this valid-descriptor ENOENT case: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get.3.html I am seeking the supported API contract, not asserting an OS defect or vulnerability. I do not want to set, delete or normalize ACLs on the objects being inspected, or treat an ambiguous result as success.
1
0
41
12h
Supported descriptor-bound distinction between absent and empty ACLs on macOS Monterey
Reported environment: macOS Monterey 12.7.6 (build 21H1320), Intel, APFS. The filesystem type of the relevant volume and exact installed implementation have not been independently reverified. I need a supported, read-only way to distinguish an absent filesystem ACL, an explicit zero-entry ACL, and unavailable/unsupported/invalid/incomplete ACL evidence while retaining an open descriptor to the object. One retained observation: an existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Path and descriptor metadata matched the expected identity, owner, mode and link count before and after the call. Exactly one acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL. Errno was cleared immediately before the call and immediately captured afterward as ENOENT. Descriptor closure succeeded. This observation does not establish ACL absence or identify the internal error path. File creation and private mode are not treated as proof of no ACL. I have not tested fgetattrlist on this host, created ACL fixtures for this inquiry, or established volume ACL capability results. Apple's published Libc-1507.100.9 source shows the fstatx_np/filesec property path, and xnu-8020.140.41 shows mode-dependent extended-security attribute packing. I am treating those as version-specific implementation evidence, not as confirmation of the installed implementation or a complete supported API contract. For this reported configuration: Which supported descriptor-bound API sequence and checked preconditions distinguish these three states? A contract applicable to Monterey and the relevant filesystem is sufficient; I am not asking for a guarantee across every macOS version or filesystem. Does NULL/ENOENT from acl_get_fd_np have a supported ACL-absence meaning under specified conditions? Can an explicit zero-entry ACL produce the same result, and how should it be distinguished? With fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, can an omitted security returned bit ever establish absence rather than unavailable evidence? Do legacy packing or a valid filesystem capability result supply a supported distinction? Please specify the applicable conditions. Does successful fstatx_np followed by filesec_query_property for FILESEC_ACL reporting an unset property distinguish absence from an unavailable observation? When a complete, valid security record is returned, what is the supported interpretation of KAUTH_FILESEC_NOACL versus an explicit entry count of zero? Is this representation intended for application-level absence verification? Please identify applicable documentation or supported technical guidance, including failure/unknown handling. Genuine retrieval errors must remain errors, and ambiguous or incomplete evidence must remain unknown. I do not want to infer success from an error, omitted attribute, invalid default or empty display, or modify an object's permissions/ACL to establish its prior state. References consulted: Apple's ACL getter manual Apple Libc-1507.100.9 ACL getter source Apple xnu-8020.140.41 attribute manual
1
0
70
12h
Which macOS version first exports Logger.isEnabled(type:)?
An app built with Xcode 27.1 for a macOS 15 deployment target called Logger.isEnabled(type:). In the SDK's swiftinterface the method sits under Logger's @available(macOS 11.0, ...) with no availability of its own, so it compiled without a warning. On macOS 15.6.1, libswiftos.dylib doesn't export it, and dyld stopped the app at launch: Symbol not found: _$s2os6LoggerV9isEnabled4typeSbSo0a5_log_E2_ta_tF Expected in: /usr/lib/swift/libswiftos.dylibThe macOS 15.5 SDK's libswiftos.tbd doesn't list the symbol and the 27 SDK does. I haven't checked macOS 26. Switching to OSLog.isEnabled(type:) fixed it. Which macOS version first exports this symbol? Write-up: https://yardlet.app/blog/logger-isenabled-macos-15.html
3
0
52
12h
MacBook Neo (A3404) kernel panic / immediate reboot when opening UVC "Room Camera" in Photo Booth (macOS 27.0.1)
Hi, We are seeing a reproducible system reboot (appears to be a kernel panic) on MacBook Neo when a third-party USB UVC camera device is opened in Photo Booth. The same setup works on another Apple Silicon Mac running the same OS version. Environment Mac: MacBook Neo, model A3404 macOS: 27.0.1 App used to open the camera: Photo Booth (system app) Device under test: our USB dongle presents a UVC composite device named "Room Camera" (USB Video Class gadget / USB camera backhaul from a room camera) Related hardware: room camera (Focus100) is attached behind an AV receiver/USB hub path, then redirected to the Mac through the dongle as a standard UVC device Our companion Mac app was uninstalled for verification; the reboot still happens, so this does not appear to depend on our app or CMIO camera extension Reproduction steps Connect the dongle to MacBook Neo A3404. Confirm that "Room Camera" is visible as a camera source. Open Photo Booth. Switch the camera source to "Room Camera". Observed result The Mac reboots immediately (100% reproducible on this Neo unit). Expected result Photo Booth should open the UVC stream normally without crashing the system. Control / comparison Same OS version (macOS 27.0.1) on MacBook Pro A3412 (M5): no reboot, camera works. Uninstalling our Mac app does not change the Neo behavior (still reboots). This suggests a host-side issue specific to MacBook Neo when starting this UVC stream (or a Neo USB/UVC host stack sensitivity to our device descriptors / isochronous stream), rather than an application-level bug in our software. Questions Are there known MacBook Neo / macOS 27 issues with external UVC devices that can cause kernel panic when a camera app (Photo Booth / FaceTime / Zoom) starts streaming? Which panic log / sysdiagnose artifacts are most useful for Apple to triage this (and which subsystem tags should we look for, e.g. UVCService / IOUSBHost / AppleUSB)? Are there known stricter UVC descriptor / configuration / bandwidth requirements on Neo versus other Apple Silicon Macs that we should validate on the gadget side? We can provide: panic reports from ~/Library/Logs/DiagnosticReports/ sysdiagnose USB device tree / IORegistry information for the UVC interface a Feedback Assistant report number if recommended Thanks for any guidance.
1
0
61
13h
Requesting com.apple.developer.vfs.snapshot for a Developer ID backup app (Team LM3P28DNVQ)
Hello, I am Ahmed Hamade, founder of Pixel Ventures LLC, Apple Developer Program Team ID LM3P28DNVQ. I am asking Apple to grant the restricted entitlement com.apple.developer.vfs.snapshot to our team for a macOS backup application named PixelProtect. If this is not the right channel, please tell me where to send the request. PixelProtect backs up a whole Mac volume. It keeps one primary backup set on a local disk and a replica of that same set in cloud storage, protects both copies against deletion, and supports recovery. We built it for people whose AI coding agents can delete data. We need snapshots for three reasons. First, files change while a backup runs, so the backup must read from one point in time to copy a consistent state. Second, snapshots let us keep local restore points without copying the data again. Third, Time Machine takes local snapshots for the same purpose. The only alternative today is tmutil localsnapshot, whose snapshots the system manages and ages out, so we could not keep restore points of our own. We would use fs_snapshot_create, fs_snapshot_list, fs_snapshot_delete and fs_snapshot_mount. We do not use fs_snapshot_revert. Restores copy files out of a mounted snapshot. Only our privileged helper calls these functions. It runs as root, is registered with SMAppService, and is packaged as an app-like bundle (planned App ID ai.pixelventures.pixelprotect.daemon) so it can embed a provisioning profile. The main app (ai.pixelventures.pixelprotect) and our command line tool send requests to the helper and do not call these functions. We limit use as follows. Snapshots are created only on volumes the user chose to back up. The user controls how long snapshots are kept. The helper deletes only snapshots it created, which carry our own name prefix, and only under the user's retention rules or an action the user confirms. PixelProtect is signed with our Developer ID Application certificate, uses the hardened runtime, is notarized, and is distributed outside the Mac App Store to Pixel Ventures clients. It is not sandboxed, because a whole-volume backup reads the whole volume. It has no public marketing page yet, so a product description is attached. Please enable the entitlement for Team ID LM3P28DNVQ for development and for Developer ID distribution, or tell me what further information you need. I tried the code-level support request form and it requires a sample project, so I am asking here as the form suggested Thank you, Ahmed Hamade Founder, Pixel Ventures LLC Team ID LM3P28DNVQ I tried the code-level support request form and it requires a sample project, so I am asking here as the form suggested
3
0
58
20h
App with shallow depth entitlement not appearing in Auto-Launch > When Submerged
I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.
4
1
918
21h
Supported SIP-on evidence for descriptor 0 at child creation/exec on macOS 27.0.1 (26A434), arm64
We need one written, reviewable capability response for the recorded system configuration: macOS 27.0.1, build 26A434; Darwin 27.0.0; xnu-13432.1.9~1/RELEASE_ARM64_T8103; arm64. These are retained host observations, not a new claim of kernel/source equivalence. The target is an application-owned non-platform Conda CPython process using its original subprocess.run/Popen calls with stdin/input omitted. We must keep System Integrity Protection enabled, preserve the original interpreter and global Python settings, and preserve executable, argv, environment, Path objects, stdin choices, timeouts, return/exception behavior and cleanup. We cannot replace the launch with a debugger-owned PTY, DEVNULL, wrapper, or changed timeout. A single harmless-target capability attempt has already been consumed. Authentication succeeded; the target's process credentials were uid/euid 501, gid/egid 20, with process group vector [20]. In that exact attempt DTrace reported at line 11: "probe description syscall:::entry does not match any probes. System Integrity Protection is on". No trace records or begin/end receipts were obtained; the target gate stayed closed and both recorded children were reaped during bounded cleanup. The diagnostic script path is intentionally omitted here; the original local raw text is preserved. We are not attributing every possible native-observation limitation solely to SIP, and we will not rerun that attempt. The single requested deliverable is CAPABILITY-RESPONSE.json (or one equivalent signed/versioned document), answering whether a named, supported mechanism on this exact configuration provides EITHER: A. A synchronous record of each original child's descriptor-0 underlying object at the accepted fork/exec boundary, including type, object/device identity and descriptor/access flags; OR B. A complete no-transient-change proof from an independently accepted descriptor-0 identity anchor over the entire original interval, covering every relevant thread and child from birth without a registration race. Please include these sections in the ONE response: disposition: SUPPORTED / UNSUPPORTED / NOT_ESTABLISHED; route A or B; responding organization/product, supported API/tool and exact version; links to public contract or a reviewable vendor coverage statement applicable to this OS/build/architecture. permissions: exact privileges, supported signing/entitlement eligibility and installation requirements; explicit statement that SIP and global Python stay unchanged. Do not assume administrative privilege alone gives kernel visibility. boundary_and_scope: how parent/child stable identities, fork/exec phase, all relevant threads and descendants, birth-registration ordering, PID reuse and cross-CPU ordering are handled; when capture starts and stops relative to the original anchor/call. coverage_and_loss: the exact guaranteed events/object fields; proof or documented guarantee of coverage; missing-event/drop/buffer-overflow/sequence-restart/error detection; the independent acceptance rule must reject any unknown interval or loss. For route B, enumerate applicable descriptor writers including direct/noncancel/guarded syscalls, open/close/dup/fcntl, received descriptors/fileports, spawn/exec file actions and close-on-exec, plus concurrency/cancellation/signal/startup paths. A short illustrative syscall list is insufficient. raw_contract: a minimal raw-record schema or already existing reference example, with observed fields distinguished from derived fields; stable process identity, phase, timestamps/sequence domain, descriptor/object identity, raw returns/errno, and coverage/error status. A source-version match or pathname alone is not an object-identity witness. preservation: how original call arguments, stdin/input omission, results/exceptions, original timeouts, original PID/wait/reap/raw streams and cleanup remain intact, and any observer effects. We cannot add waits, kills, reads or retries to fill missing original evidence. prospective_validation: a finite, independently reviewable validation plan only, with success criteria and false-acceptance controls for missing records, descriptor replacement/ABA, unobserved early children and stream loss. No launch, sudo command, new probe iteration or installation is authorized by this request. If no supported mechanism satisfies either route, please say UNSUPPORTED and name the missing public capability; if applicability is unknown, say NOT_ESTABLISHED. Do not substitute a generic follow-fork setting, a late process/fd snapshot, an EndpointSecurity descriptor subset/type list, successful compilation, source version numbers, or a recommendation to disable SIP/change stdin. A positive written response permits only independent design/source/coverage review. It does not prove our actual descriptor-0 chain and grants no project verification credit. Only after pre-review passes could a separately bound, new finite observation request be considered. No historical missing data will be reconstructed or old completed validations repeated. This is one specific supported-API/capability question, not a request for Apple to develop our collector or disclose private implementation. No repository sources, account secrets, credentials, private paths or runtime databases are attached. No existing observation tool or build materials are requested from our end user.
1
0
102
21h
How to get file size before and after write operations using Endpoint Security?
Hello, I am working on an audit of file operations for a DLP agent. I am trying to implement this mechanism using Endpoint Security. One of the customer's requirements is that write event reports must provide information about the file size both before and after the write operation. The challenge is that the ES_EVENT_TYPE_NOTIFY_WRITE event does not provide information about the changes, and in the stat structure, I see the file's stat prior to the write event. I tried to implement a mechanism based on tracking the sequence of events (open -> write -> close), but it seems macOS does not guarantee such a sequence, as the agent receives ES_EVENT_TYPE_NOTIFY_CLOSE earlier than ES_EVENT_TYPE_NOTIFY_OPEN. Unfortunately, Auth events cannot be used due to no guarantee the DLP agent is the only ES client. Is there any way within the Endpoint Security Framework to guarantee the sequence of NOTIFY events? Are there any other supported (public) APIs or methods besides Endpoint Security to track file system changes? As far as I know, ktrace (which powers fs_usage) is a private framework. Thank you in advance!
6
0
119
1d
Broken Private Relay and Black Screen Issues with 26.6.2 and 27.0 Virtual Machines
There have been 2 serious regressions in the hypervisor framework since developer beta 6 of macOS 27 that have continued into the final release, and the first beta of 27.2 The first is that since developer beta 6 of macOS 27, virtual machines that have an Apple ID with iCloud+ signed in fail to route traffic in Safari through iCloud Private Relay despite it being on. Parallels, UTM, VirtualBuddy have all been tested and the issue applies to all of them, exposing the host machine's IP address. I have reported the issue since I discovered it and there hasn't been any communication that Apple even knows its an issue to my open report in Feedback Assistant. The second issue is a newer one, and it affects macOS 26.6.2 and earlier virtual machines. Attempting to install 26.7 through the built-in software update causes the virtual machine to black screen upon reboot during the installation. Forcing the machine off and back on causes the virtual machine to revert back to macOS 26.6.2. There has been no available IPSW file to test if a clean install of 26.7 in a virtual machine is a viable workaround, or to see if there is a bug in the updating mechanism or bug in the 26.7 release itself in virtual machines. The Parallels Desktop forum is beginning to get reports from users of that software of the same black screen issue trying to update their own 26.6.2 VMs to 26.7. These issues have also not been corrected in either 27.2 Beta 1 nor 26.7.1 Has anyone found a workaround to either of these 2 issues, or submitted similar reports and got any kind of response from Apple? The feedback reports about these issues are FB24828992 and FB24791716
10
1
1k
1d
How can my app use SMAppService to re-register a launch daemon when the app's location has changed?
I'm developing an app that uses SMAppService to register a launch daemon. I'm running into big troubles with having the daemon start up reliably because, over the course of testing, the location of my app bundle has changed. Various workflows for this app require testing it running from with /Applications, /Applications/Utilities, or in the project's build directories, which includes both debug and release builds. And I need to account for users moving the app bundle around. The trouble is that the launch daemon seems to want to launch from the first path it was registered, not at the path it was last registered. For example, if my app originally registered it while located in /Applications/MyApp.app, then the launch daemon will only run from within an app bundle at that specific location, even if there is no app bundle at that path. As per advice on these forums, I've tried accounting for this by unregistering the daemon, waiting two seconds, and then re-registering it. But in practice this isn't working. I can use sfltool dumbtm and see that the app is still registered in /Applications/MyApp.app and not its new location, and the launch daemon simply silently fails to launch -- SMAppService returns no error. sudo launchctl list displays the job as having status 78. If I set up a stdout/stderr redireciton in its job file, the files are empty. (I'm aware that I can use sfltool resetbtm to completely reset all login items and background tasks and temporarily fix this issue at least on my own system, but I can hardly have my app use that as part of its standard installation procedure. I need some way of dealing with this that doesn't requiring reseting the state of every app that has a background item.) I'm starting to pull my hair out dealing with this! (Figuratively, mind you. Not literally, at least not yet.) How can I get this to work? This API is starting to seem like a downgrade from placing a plist file in /Library/LaunchDaemons because at least that was able to work very reliably.
11
0
374
1d
Supported data-only export of development source files carrying `com.apple.macl`
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.
2
0
142
1d
macos: Supported API to establish filesystem ACL absence?
I'm implementing a security-sensitive filesystem metadata verifier on macOS 27.0.1 (Apple Silicon, MacOSX27.0.sdk). The verifier must distinguish three states: ACL absent: Supported evidence establishes that the file or directory has no filesystem ACL. ACL present: An ACL exists, including an empty ACL. Unknown: The observation is ambiguous, unavailable, unsupported, or incomplete. Only authoritative ACL absence is acceptable. All other states are rejected. I'm investigating fstatx_np() with a filesec_t object, followed by filesec_query_property(security, FILESEC_ACL, &present). My questions are: Does this combination provide a supported API guarantee that a file or directory has no ACL when present is reported as false? Can an unset FILESEC_ACL property be reliably distinguished from an omitted or unavailable ACL observation? If this mechanism cannot establish absence, is there another supported descriptor-based macOS API that can? Is there Apple documentation specifying these semantics, including relevant error and unsupported-operation behavior? I am not treating an empty ACL entry list, an unset property, or a command-line display without ACL entries as proof of absence. I'm seeking the native API contract so the verifier can fail closed whenever ACL absence is not authoritatively established.
1
0
123
1d
Core OS Resources
General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"
Replies
0
Boosts
0
Views
2.2k
Activity
Aug ’25
macOS: How to reliably verify the absence of an extended ACL using a file descriptor?
We are implementing a fail-closed security check for a directory opened through a file descriptor on macOS. We need to reliably distinguish between: No extended ACL is present. An extended ACL is present but contains zero entries. ACL retrieval failed or is unsupported. Observed behavior For an existing directory with mode 0700: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. acl_get_file(path, ACL_TYPE_EXTENDED) returns NULL with errno == ENOENT. fstat() and lstat() agree on the device and inode. The directory exists and can be opened successfully. ls -ldeO@ displays no extended ACL entries. We reviewed Apple's open-source implementations of acl_get_fd_np() and filesec_get_property(). We understand that ENOENT can result from an unavailable FILESEC_ACL property, rather than a missing filesystem object. We also understand that XNU distinguishes an empty ACL from KAUTH_FILESEC_NOACL. Question Is there a publicly supported, file-descriptor-based API with documented postconditions that can reliably prove the absence of an extended ACL, while distinguishing it from an empty ACL and an ACL retrieval failure? Specifically: Can fstatx_np() and filesec_get_property() provide this distinction? Can fgetattrlist() with ATTR_CMN_EXTENDED_SECURITY and ATTR_CMN_RETURNED_ATTRS reliably establish ACL absence? What additional filesystem capability checks or return-value checks are required? If no public API provides this guarantee, is that a documented limitation? For security reasons, our implementation rejects the object whenever ACL absence cannot be established reliably. We would appreciate clarification of the supported API contract and its limitations. Thank you.
Replies
1
Boosts
0
Views
39
Activity
59m
macOS 27/APFS: Supported ACL Absence Verification When acl_get_fd_np Returns ENOENT
Subject: Supported fail-closed ACL absence verification on macOS 27.0.1 / APFS Environment: macOS 27.0.1, build 26A434; APFS; installed macOS 27.0 SDK. We need a supported, documented way to determine whether an existing filesystem object has no effective ACL entries, while rejecting genuine retrieval failures and unsupported or unavailable ACL evidence. We are seeking clarification of the public interface contract, not alleging an Apple defect. For existing directory and regular-file fixtures, pathname metadata and descriptor metadata identify the same object. Errno is cleared immediately before each native call and captured immediately afterward. ACL retrieval uses ACL_TYPE_EXTENDED: acl_get_file(path, ACL_TYPE_EXTENDED) acl_get_fd_np(fd, ACL_TYPE_EXTENDED) On fresh objects, both return NULL with ENOENT. Explicit one-entry fixture ACLs are retrieved successfully. Explicit zero-entry fixture ACLs can also yield NULL/ENOENT, while attribute queries return a serialized zero-entry ACL. The attribute queries use getattrlist() and descriptor-bound fgetattrlist(), requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_NOFOLLOW | FSOPT_REPORT_FULLSIZE and WITHOUT FSOPT_PACK_INVAL_ATTRS. Buffer lengths, variable-reference bounds and returned-attribute validity are checked. For the existing directories of interest, both calls succeed but omit the ATTR_CMN_EXTENDED_SECURITY returned bit. Explicit populated and zero-entry fixture records do set the bit. APFS reports valid VOL_CAP_INT_EXTENDED_SECURITY support; we do not assume that volume capability proves per-object ACL availability. On macOS 27.0.1, build 26A434, using APFS, which supported interface and documented conditions allow software to distinguish an absent ACL from unavailable or unsupported ACL evidence when descriptor-bound attribute queries succeed but omit ATTR_CMN_EXTENDED_SECURITY and native ACL getters return ENOENT for an existing object? Please clarify: Whether ENOENT has a supported ACL-absence interpretation, and under exactly which checked conditions. Whether an omitted extended-security attribute can establish ACL absence, rather than unavailable or unsupported evidence. How explicit zero-entry ACLs differ from absent ACL records through supported interfaces. How KAUTH_FILESEC_NOACL should be interpreted through supported APIs. How genuine retrieval failures, including permission, I/O, allocation and unsupported-operation errors, must remain distinguishable. Whether a supported descriptor-bound verification method exists that preserves fail-closed security checks and object identity binding; please identify its guarantees and limitations regarding pathname/ancestor changes and later operations. Whether relevant behavior is specific to this macOS/APFS version. Please identify the applicable public documentation or supported verification sequence. We do not want to modify permissions, synthesize ACLs on target objects, treat invalid-attribute defaults as real evidence, or accept ambiguous omission/ENOENT as success. Existing ownership, mode and confinement checks must remain separate mandatory checks. If no public API can make this distinction reliably, please state that limitation.
Replies
3
Boosts
0
Views
291
Activity
1h
How can a macOS application establish that an open APFS file has no extended ACL?
On macOS 26.5.2 (build 25F84), which documented API and return conditions, if any, establish that a regular file on APFS has no extended access control list (ACL), using an already-open file descriptor? We tested three disposable regular files on an APFS volume reporting ACL support. For each file, we opened a read-only file descriptor and called: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY Before and after inspection, fstat() confirmed stable device, inode, mode, and change timestamp. Observed results: 1. Newly created file, no ACL explicitly assigned acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() succeeded but omitted ATTR_CMN_EXTENDED_SECURITY from the returned attribute mask. FSOPT_PACK_INVAL_ATTRS also left that bit clear. 2. File with an explicitly assigned empty ACL acl_get_fd_np() returned NULL with errno == ENOENT. fgetattrlist() returned the extended-security attribute with an ACL entry count of zero. 3. File with one explicit ACL entry acl_get_fd_np() returned a non-null ACL. fgetattrlist() returned the extended-security attribute with an ACL entry count of one. Apple's published XNU attribute-packing implementation appears to use the same omission branch when ACL metadata is unsupported or when the ACL pointer is null. My question: Is there a supported descriptor-based API sequence that reliably distinguishes: Genuine absence of an extended ACL Unavailable or unsupported per-file ACL metadata An ACL retrieval failure If so, which API, capability checks, return values, attribute bits, or error conditions should a caller rely on? Are there relevant APFS or macOS version limitations? If the public API cannot establish ACL absence unambiguously in this situation, confirmation of that limitation would also be helpful. Thank you for your guidance.
Replies
1
Boosts
0
Views
29
Activity
1h
Import resulting certificate to associate with private key
On macOS I am creating a public/private key pair (ECDSA 256), will be secure enclave in the long run, just trying to baseline some functionality right now using file store (currently running in a system daemon). I can sign data using the private key with no problem, and export the public key. However, after generating a cert chain via CSR externally, I’m trying to figure out the proper incantation to import that cert/chain and have it recognized as matching the existing private key, but so far I can’t figure out the correct attributes to get it to pair up. Do you have any sample code that might have the right SecAddItem (or such) calls that would make this work as expected?
Replies
9
Boosts
0
Views
2.1k
Activity
5h
Installing a macOS guest onto an external USB disk with Virtualization.framework (sandboxed app)
Hello, We develop a sandboxed Mac App Store app that runs virtual machines with Virtualization.framework on Apple silicon (macOS 27). Users want to install a macOS guest onto an external USB disk and start the VM from it, so they can keep a VM on portable storage or on a disk larger than the Mac's internal drive. What we tried USB passthrough: we attach the disk before the VM starts, with VZUSBPassthroughDeviceConfiguration (from an AAUSBAccessory) on a VZXHCIControllerConfiguration. Linux guests install onto the disk and boot from it without problems. For a macOS guest, VZMacOSInstaller fails to start when the USB disk is the only storage: As we understand it, a macOS VM can only start from its own storage devices, never from a USB device, so even a successful install would not boot. VZDiskBlockDeviceStorageDeviceAttachment: this needs an open file handle to /dev/diskN. That requires admin rights, which a sandboxed app can't obtain, so we can't use it in our App Store app. Questions Is there a supported way to install a macOS guest onto an external USB disk and start the VM from it? Is there a sandbox-compatible way to get a VZDiskBlockDeviceStorageDeviceAttachment for an external disk, for example after user consent, similar to how AccessoryAccess grants USB devices? If neither is possible today, is support for this planned, or is there a recommended alternative? Thank you for any guidance.
Replies
5
Boosts
0
Views
87
Activity
6h
Using tcsetattr on stdin in sandboxed CLI app does not work due ioctl restriction
Our (sandboxed, distributed through the Mac App Store) app can optionally run as a CLI tool, to allow users to use it in scripts and other automation contexts. One of the usecases involves being a wrapper for the ssh command, but the ssh binary is not able to enable raw mode for stdin due to a sandbox violation (bug report). As a reduced example, I've created https://github.com/mihaip/sandboxed-cli-test, which has a minimal C program that uses tcsetattr to set attributes on stdin. That fails, and sandboxd logs to the console Sandbox: SandboxedCLI(30110) deny(1) file-ioctl /dev/ttys012. If I disable sandboxing on the binary then it works as expected. Looking through the sandbox profiles on /System/Library/Sandbox/Profiles, I'm not seeing cases where file-ioctl is enabled on /dev/tty. Are we out of luck, or is there a workaround?
Replies
1
Boosts
5
Views
1.4k
Activity
9h
Supported provenance handling when copying a verified helper
What supported public contract should software use for com.apple.provenance when copying an exact expected helper binary into a new, private owner-controlled working directory for separately authorized later use? We want to leave originals unchanged, preserve security protections, and avoid removing, decoding or reconstructing opaque Apple attribute values. Program-byte identity, permissions/custody and code validation are separate from this metadata question; an attribute name or copy success is not treated as a trust decision. Public APIs reviewed: fcopyfile with independent DATA/XATTR selection, and xattr_flags_from_name with xattr_intent_with_flags for COPY intent. A bounded public-constant probe returned zero property flags and the default preserve result for both com.apple.provenance and an invented unknown name. We therefore do not interpret that default as proof of recognition or an exemption. Could you clarify: Which supported metadata postconditions apply to this specific copy use? Is source/destination raw-value equality an appropriate invariant for this opaque attribute, or may the OS legitimately create different destination metadata while preserving the intended security behavior? Which public properties or APIs can establish the intended destination state without parsing/removing private values or weakening OS protections? The xattr manual's named-wrapper return sentence appears inconsistent with its flags-based description/example. What is the supported return-polarity contract, and is using the flags-based function the intended interpretation? This asks for supported semantics, not a bypass or private value format. No paths, binaries, source, attribute values, keys, account data or logs are attached. Public references: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/fcopyfile.3.html https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_name_with_flags.3 https://github.com/apple-oss-distributions/copyfile/blob/main/xattr_flags.h
Replies
1
Boosts
0
Views
81
Activity
12h
macOS/APFS: interpreting acl_get_fd_np ENOENT and omitted extended-security attributes
Apple Support directed me to the Developer Forums for this API-contract question. I am implementing conservative, read-only ACL classification for existing files and directories. I need to distinguish an absent ACL from unavailable or incomplete ACL information. Ambiguous results are currently rejected. The measurements below were taken on macOS 26.5, build 25F71, Apple Silicon (arm64), on APFS. Method I tested eight newly created objects: a regular file and a directory in each of four preparation states: Fresh: no ACL setter, deletion or normalization was performed. Explicit-empty ACL preparation. One DENY entry. One ALLOW entry. “Fresh” describes preparation only; I am not assuming it independently proves ACL absence. Each object remained open through preparation and two observations using the same file descriptor. Each observation performed: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) fgetattrlist() requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_REPORT_FULLSIZE and without FSOPT_PACK_INVAL_ATTRS. Errno was cleared immediately before each query and captured immediately afterward. Descriptor/path identity and metadata stability were checked. Returned lengths, attribute bitmaps and applicable reference/payload bounds were validated. Observations Results matched between the two observations and between regular files and directories: Preparationacl_get_fd_np resultfgetattrlist returnEXTENDED_SECURITY returnedReturned filesec ACE countAttribute-buffer lengthFreshNULL, errno ENOENT0NoN/A32 bytesExplicit-emptyNULL, errno ENOENT0Yes076 bytesOne DENY entryNon-NULL, errno 00Yes1100 bytesOne ALLOW entryNon-NULL, errno 00Yes1100 bytesWhen the getter returned NULL, ACL validation and enumeration were not performed; their results are N/A, not measured zeros or an empty entry list. When EXTENDED_SECURITY was omitted, its payload fields were unavailable. I did not interpret default buffer values as returned ACL information. An actually returned zero-entry record is distinct from omission. No NOACL sentinel was observed in this experiment. Question For a valid descriptor referring to an existing APFS object, what is the supported interpretation of: acl_get_fd_np(fd, ACL_TYPE_EXTENDED) returning NULL with ENOENT; and fgetattrlist() succeeding while omitting ATTR_CMN_EXTENDED_SECURITY from the returned attribute bitmap? In particular: Can this combination establish ACL absence under documented conditions, or must it remain classified as unavailable/ambiguous information? How should the observed NULL/ENOENT with an actually returned zero-entry ACL record be interpreted? If these results cannot establish absence, which supported read-only, descriptor-based API or verification sequence should be used? What guarantees and limitations apply regarding macOS versions, filesystem support and genuine retrieval failures? I reviewed the acl_get(3) documentation but could not find a clear explanation of this valid-descriptor ENOENT case: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get.3.html I am seeking the supported API contract, not asserting an OS defect or vulnerability. I do not want to set, delete or normalize ACLs on the objects being inspected, or treat an ambiguous result as success.
Replies
1
Boosts
0
Views
41
Activity
12h
Supported descriptor-bound distinction between absent and empty ACLs on macOS Monterey
Reported environment: macOS Monterey 12.7.6 (build 21H1320), Intel, APFS. The filesystem type of the relevant volume and exact installed implementation have not been independently reverified. I need a supported, read-only way to distinguish an absent filesystem ACL, an explicit zero-entry ACL, and unavailable/unsupported/invalid/incomplete ACL evidence while retaining an open descriptor to the object. One retained observation: an existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Path and descriptor metadata matched the expected identity, owner, mode and link count before and after the call. Exactly one acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL. Errno was cleared immediately before the call and immediately captured afterward as ENOENT. Descriptor closure succeeded. This observation does not establish ACL absence or identify the internal error path. File creation and private mode are not treated as proof of no ACL. I have not tested fgetattrlist on this host, created ACL fixtures for this inquiry, or established volume ACL capability results. Apple's published Libc-1507.100.9 source shows the fstatx_np/filesec property path, and xnu-8020.140.41 shows mode-dependent extended-security attribute packing. I am treating those as version-specific implementation evidence, not as confirmation of the installed implementation or a complete supported API contract. For this reported configuration: Which supported descriptor-bound API sequence and checked preconditions distinguish these three states? A contract applicable to Monterey and the relevant filesystem is sufficient; I am not asking for a guarantee across every macOS version or filesystem. Does NULL/ENOENT from acl_get_fd_np have a supported ACL-absence meaning under specified conditions? Can an explicit zero-entry ACL produce the same result, and how should it be distinguished? With fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, can an omitted security returned bit ever establish absence rather than unavailable evidence? Do legacy packing or a valid filesystem capability result supply a supported distinction? Please specify the applicable conditions. Does successful fstatx_np followed by filesec_query_property for FILESEC_ACL reporting an unset property distinguish absence from an unavailable observation? When a complete, valid security record is returned, what is the supported interpretation of KAUTH_FILESEC_NOACL versus an explicit entry count of zero? Is this representation intended for application-level absence verification? Please identify applicable documentation or supported technical guidance, including failure/unknown handling. Genuine retrieval errors must remain errors, and ambiguous or incomplete evidence must remain unknown. I do not want to infer success from an error, omitted attribute, invalid default or empty display, or modify an object's permissions/ACL to establish its prior state. References consulted: Apple's ACL getter manual Apple Libc-1507.100.9 ACL getter source Apple xnu-8020.140.41 attribute manual
Replies
1
Boosts
0
Views
70
Activity
12h
Which macOS version first exports Logger.isEnabled(type:)?
An app built with Xcode 27.1 for a macOS 15 deployment target called Logger.isEnabled(type:). In the SDK's swiftinterface the method sits under Logger's @available(macOS 11.0, ...) with no availability of its own, so it compiled without a warning. On macOS 15.6.1, libswiftos.dylib doesn't export it, and dyld stopped the app at launch: Symbol not found: _$s2os6LoggerV9isEnabled4typeSbSo0a5_log_E2_ta_tF Expected in: /usr/lib/swift/libswiftos.dylibThe macOS 15.5 SDK's libswiftos.tbd doesn't list the symbol and the 27 SDK does. I haven't checked macOS 26. Switching to OSLog.isEnabled(type:) fixed it. Which macOS version first exports this symbol? Write-up: https://yardlet.app/blog/logger-isenabled-macos-15.html
Replies
3
Boosts
0
Views
52
Activity
12h
MacBook Neo (A3404) kernel panic / immediate reboot when opening UVC "Room Camera" in Photo Booth (macOS 27.0.1)
Hi, We are seeing a reproducible system reboot (appears to be a kernel panic) on MacBook Neo when a third-party USB UVC camera device is opened in Photo Booth. The same setup works on another Apple Silicon Mac running the same OS version. Environment Mac: MacBook Neo, model A3404 macOS: 27.0.1 App used to open the camera: Photo Booth (system app) Device under test: our USB dongle presents a UVC composite device named "Room Camera" (USB Video Class gadget / USB camera backhaul from a room camera) Related hardware: room camera (Focus100) is attached behind an AV receiver/USB hub path, then redirected to the Mac through the dongle as a standard UVC device Our companion Mac app was uninstalled for verification; the reboot still happens, so this does not appear to depend on our app or CMIO camera extension Reproduction steps Connect the dongle to MacBook Neo A3404. Confirm that "Room Camera" is visible as a camera source. Open Photo Booth. Switch the camera source to "Room Camera". Observed result The Mac reboots immediately (100% reproducible on this Neo unit). Expected result Photo Booth should open the UVC stream normally without crashing the system. Control / comparison Same OS version (macOS 27.0.1) on MacBook Pro A3412 (M5): no reboot, camera works. Uninstalling our Mac app does not change the Neo behavior (still reboots). This suggests a host-side issue specific to MacBook Neo when starting this UVC stream (or a Neo USB/UVC host stack sensitivity to our device descriptors / isochronous stream), rather than an application-level bug in our software. Questions Are there known MacBook Neo / macOS 27 issues with external UVC devices that can cause kernel panic when a camera app (Photo Booth / FaceTime / Zoom) starts streaming? Which panic log / sysdiagnose artifacts are most useful for Apple to triage this (and which subsystem tags should we look for, e.g. UVCService / IOUSBHost / AppleUSB)? Are there known stricter UVC descriptor / configuration / bandwidth requirements on Neo versus other Apple Silicon Macs that we should validate on the gadget side? We can provide: panic reports from ~/Library/Logs/DiagnosticReports/ sysdiagnose USB device tree / IORegistry information for the UVC interface a Feedback Assistant report number if recommended Thanks for any guidance.
Replies
1
Boosts
0
Views
61
Activity
13h
Requesting com.apple.developer.vfs.snapshot for a Developer ID backup app (Team LM3P28DNVQ)
Hello, I am Ahmed Hamade, founder of Pixel Ventures LLC, Apple Developer Program Team ID LM3P28DNVQ. I am asking Apple to grant the restricted entitlement com.apple.developer.vfs.snapshot to our team for a macOS backup application named PixelProtect. If this is not the right channel, please tell me where to send the request. PixelProtect backs up a whole Mac volume. It keeps one primary backup set on a local disk and a replica of that same set in cloud storage, protects both copies against deletion, and supports recovery. We built it for people whose AI coding agents can delete data. We need snapshots for three reasons. First, files change while a backup runs, so the backup must read from one point in time to copy a consistent state. Second, snapshots let us keep local restore points without copying the data again. Third, Time Machine takes local snapshots for the same purpose. The only alternative today is tmutil localsnapshot, whose snapshots the system manages and ages out, so we could not keep restore points of our own. We would use fs_snapshot_create, fs_snapshot_list, fs_snapshot_delete and fs_snapshot_mount. We do not use fs_snapshot_revert. Restores copy files out of a mounted snapshot. Only our privileged helper calls these functions. It runs as root, is registered with SMAppService, and is packaged as an app-like bundle (planned App ID ai.pixelventures.pixelprotect.daemon) so it can embed a provisioning profile. The main app (ai.pixelventures.pixelprotect) and our command line tool send requests to the helper and do not call these functions. We limit use as follows. Snapshots are created only on volumes the user chose to back up. The user controls how long snapshots are kept. The helper deletes only snapshots it created, which carry our own name prefix, and only under the user's retention rules or an action the user confirms. PixelProtect is signed with our Developer ID Application certificate, uses the hardened runtime, is notarized, and is distributed outside the Mac App Store to Pixel Ventures clients. It is not sandboxed, because a whole-volume backup reads the whole volume. It has no public marketing page yet, so a product description is attached. Please enable the entitlement for Team ID LM3P28DNVQ for development and for Developer ID distribution, or tell me what further information you need. I tried the code-level support request form and it requires a sample project, so I am asking here as the form suggested Thank you, Ahmed Hamade Founder, Pixel Ventures LLC Team ID LM3P28DNVQ I tried the code-level support request form and it requires a sample project, so I am asking here as the form suggested
Replies
3
Boosts
0
Views
58
Activity
20h
App with shallow depth entitlement not appearing in Auto-Launch > When Submerged
I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.
Replies
4
Boosts
1
Views
918
Activity
21h
Supported SIP-on evidence for descriptor 0 at child creation/exec on macOS 27.0.1 (26A434), arm64
We need one written, reviewable capability response for the recorded system configuration: macOS 27.0.1, build 26A434; Darwin 27.0.0; xnu-13432.1.9~1/RELEASE_ARM64_T8103; arm64. These are retained host observations, not a new claim of kernel/source equivalence. The target is an application-owned non-platform Conda CPython process using its original subprocess.run/Popen calls with stdin/input omitted. We must keep System Integrity Protection enabled, preserve the original interpreter and global Python settings, and preserve executable, argv, environment, Path objects, stdin choices, timeouts, return/exception behavior and cleanup. We cannot replace the launch with a debugger-owned PTY, DEVNULL, wrapper, or changed timeout. A single harmless-target capability attempt has already been consumed. Authentication succeeded; the target's process credentials were uid/euid 501, gid/egid 20, with process group vector [20]. In that exact attempt DTrace reported at line 11: "probe description syscall:::entry does not match any probes. System Integrity Protection is on". No trace records or begin/end receipts were obtained; the target gate stayed closed and both recorded children were reaped during bounded cleanup. The diagnostic script path is intentionally omitted here; the original local raw text is preserved. We are not attributing every possible native-observation limitation solely to SIP, and we will not rerun that attempt. The single requested deliverable is CAPABILITY-RESPONSE.json (or one equivalent signed/versioned document), answering whether a named, supported mechanism on this exact configuration provides EITHER: A. A synchronous record of each original child's descriptor-0 underlying object at the accepted fork/exec boundary, including type, object/device identity and descriptor/access flags; OR B. A complete no-transient-change proof from an independently accepted descriptor-0 identity anchor over the entire original interval, covering every relevant thread and child from birth without a registration race. Please include these sections in the ONE response: disposition: SUPPORTED / UNSUPPORTED / NOT_ESTABLISHED; route A or B; responding organization/product, supported API/tool and exact version; links to public contract or a reviewable vendor coverage statement applicable to this OS/build/architecture. permissions: exact privileges, supported signing/entitlement eligibility and installation requirements; explicit statement that SIP and global Python stay unchanged. Do not assume administrative privilege alone gives kernel visibility. boundary_and_scope: how parent/child stable identities, fork/exec phase, all relevant threads and descendants, birth-registration ordering, PID reuse and cross-CPU ordering are handled; when capture starts and stops relative to the original anchor/call. coverage_and_loss: the exact guaranteed events/object fields; proof or documented guarantee of coverage; missing-event/drop/buffer-overflow/sequence-restart/error detection; the independent acceptance rule must reject any unknown interval or loss. For route B, enumerate applicable descriptor writers including direct/noncancel/guarded syscalls, open/close/dup/fcntl, received descriptors/fileports, spawn/exec file actions and close-on-exec, plus concurrency/cancellation/signal/startup paths. A short illustrative syscall list is insufficient. raw_contract: a minimal raw-record schema or already existing reference example, with observed fields distinguished from derived fields; stable process identity, phase, timestamps/sequence domain, descriptor/object identity, raw returns/errno, and coverage/error status. A source-version match or pathname alone is not an object-identity witness. preservation: how original call arguments, stdin/input omission, results/exceptions, original timeouts, original PID/wait/reap/raw streams and cleanup remain intact, and any observer effects. We cannot add waits, kills, reads or retries to fill missing original evidence. prospective_validation: a finite, independently reviewable validation plan only, with success criteria and false-acceptance controls for missing records, descriptor replacement/ABA, unobserved early children and stream loss. No launch, sudo command, new probe iteration or installation is authorized by this request. If no supported mechanism satisfies either route, please say UNSUPPORTED and name the missing public capability; if applicability is unknown, say NOT_ESTABLISHED. Do not substitute a generic follow-fork setting, a late process/fd snapshot, an EndpointSecurity descriptor subset/type list, successful compilation, source version numbers, or a recommendation to disable SIP/change stdin. A positive written response permits only independent design/source/coverage review. It does not prove our actual descriptor-0 chain and grants no project verification credit. Only after pre-review passes could a separately bound, new finite observation request be considered. No historical missing data will be reconstructed or old completed validations repeated. This is one specific supported-API/capability question, not a request for Apple to develop our collector or disclose private implementation. No repository sources, account secrets, credentials, private paths or runtime databases are attached. No existing observation tool or build materials are requested from our end user.
Replies
1
Boosts
0
Views
102
Activity
21h
How to get file size before and after write operations using Endpoint Security?
Hello, I am working on an audit of file operations for a DLP agent. I am trying to implement this mechanism using Endpoint Security. One of the customer's requirements is that write event reports must provide information about the file size both before and after the write operation. The challenge is that the ES_EVENT_TYPE_NOTIFY_WRITE event does not provide information about the changes, and in the stat structure, I see the file's stat prior to the write event. I tried to implement a mechanism based on tracking the sequence of events (open -> write -> close), but it seems macOS does not guarantee such a sequence, as the agent receives ES_EVENT_TYPE_NOTIFY_CLOSE earlier than ES_EVENT_TYPE_NOTIFY_OPEN. Unfortunately, Auth events cannot be used due to no guarantee the DLP agent is the only ES client. Is there any way within the Endpoint Security Framework to guarantee the sequence of NOTIFY events? Are there any other supported (public) APIs or methods besides Endpoint Security to track file system changes? As far as I know, ktrace (which powers fs_usage) is a private framework. Thank you in advance!
Replies
6
Boosts
0
Views
119
Activity
1d
Broken Private Relay and Black Screen Issues with 26.6.2 and 27.0 Virtual Machines
There have been 2 serious regressions in the hypervisor framework since developer beta 6 of macOS 27 that have continued into the final release, and the first beta of 27.2 The first is that since developer beta 6 of macOS 27, virtual machines that have an Apple ID with iCloud+ signed in fail to route traffic in Safari through iCloud Private Relay despite it being on. Parallels, UTM, VirtualBuddy have all been tested and the issue applies to all of them, exposing the host machine's IP address. I have reported the issue since I discovered it and there hasn't been any communication that Apple even knows its an issue to my open report in Feedback Assistant. The second issue is a newer one, and it affects macOS 26.6.2 and earlier virtual machines. Attempting to install 26.7 through the built-in software update causes the virtual machine to black screen upon reboot during the installation. Forcing the machine off and back on causes the virtual machine to revert back to macOS 26.6.2. There has been no available IPSW file to test if a clean install of 26.7 in a virtual machine is a viable workaround, or to see if there is a bug in the updating mechanism or bug in the 26.7 release itself in virtual machines. The Parallels Desktop forum is beginning to get reports from users of that software of the same black screen issue trying to update their own 26.6.2 VMs to 26.7. These issues have also not been corrected in either 27.2 Beta 1 nor 26.7.1 Has anyone found a workaround to either of these 2 issues, or submitted similar reports and got any kind of response from Apple? The feedback reports about these issues are FB24828992 and FB24791716
Replies
10
Boosts
1
Views
1k
Activity
1d
How can my app use SMAppService to re-register a launch daemon when the app's location has changed?
I'm developing an app that uses SMAppService to register a launch daemon. I'm running into big troubles with having the daemon start up reliably because, over the course of testing, the location of my app bundle has changed. Various workflows for this app require testing it running from with /Applications, /Applications/Utilities, or in the project's build directories, which includes both debug and release builds. And I need to account for users moving the app bundle around. The trouble is that the launch daemon seems to want to launch from the first path it was registered, not at the path it was last registered. For example, if my app originally registered it while located in /Applications/MyApp.app, then the launch daemon will only run from within an app bundle at that specific location, even if there is no app bundle at that path. As per advice on these forums, I've tried accounting for this by unregistering the daemon, waiting two seconds, and then re-registering it. But in practice this isn't working. I can use sfltool dumbtm and see that the app is still registered in /Applications/MyApp.app and not its new location, and the launch daemon simply silently fails to launch -- SMAppService returns no error. sudo launchctl list displays the job as having status 78. If I set up a stdout/stderr redireciton in its job file, the files are empty. (I'm aware that I can use sfltool resetbtm to completely reset all login items and background tasks and temporarily fix this issue at least on my own system, but I can hardly have my app use that as part of its standard installation procedure. I need some way of dealing with this that doesn't requiring reseting the state of every app that has a background item.) I'm starting to pull my hair out dealing with this! (Figuratively, mind you. Not literally, at least not yet.) How can I get this to work? This API is starting to seem like a downgrade from placing a plist file in /Library/LaunchDaemons because at least that was able to work very reliably.
Replies
11
Boosts
0
Views
374
Activity
1d
Supported data-only export of development source files carrying `com.apple.macl`
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.
Replies
2
Boosts
0
Views
142
Activity
1d
macos: Supported API to establish filesystem ACL absence?
I'm implementing a security-sensitive filesystem metadata verifier on macOS 27.0.1 (Apple Silicon, MacOSX27.0.sdk). The verifier must distinguish three states: ACL absent: Supported evidence establishes that the file or directory has no filesystem ACL. ACL present: An ACL exists, including an empty ACL. Unknown: The observation is ambiguous, unavailable, unsupported, or incomplete. Only authoritative ACL absence is acceptable. All other states are rejected. I'm investigating fstatx_np() with a filesec_t object, followed by filesec_query_property(security, FILESEC_ACL, &present). My questions are: Does this combination provide a supported API guarantee that a file or directory has no ACL when present is reported as false? Can an unset FILESEC_ACL property be reliably distinguished from an omitted or unavailable ACL observation? If this mechanism cannot establish absence, is there another supported descriptor-based macOS API that can? Is there Apple documentation specifying these semantics, including relevant error and unsupported-operation behavior? I am not treating an empty ACL entry list, an unset property, or a command-line display without ACL entries as proof of absence. I'm seeking the native API contract so the verifier can fail closed whenever ACL absence is not authoritatively established.
Replies
1
Boosts
0
Views
123
Activity
1d