Configuration being evaluated: macOS 15.4.1 (24E263), Apple silicon, Apple's native APFS, and an existing executable that calls fsync(fd) on an already-open regular file. This is the selected configuration for our question, not a claim that a new runtime qualification has been completed. We need to preserve the executable's original call semantics and the native APFS target. We are not proposing a replacement filesystem, a modified fsync implementation in the executable, or a private kernel patch. Is there a documented, customer-deployable interface for synchronously rejecting this particular fsync request before the filesystem accepts or begins the synchronization work attributable to that request? The critical schedule is: an initial check allows the request; execution is delayed; a deadline expires or the originating thread/operation loses its authorization; the request then tries to begin. We need to know whether a supported interface can prevent that still-unstarted request from proceeding, rather than merely report an error after it has begun. If such an interface exists, please identify: The API and supported OS versions, including availability on the configuration above, plus any entitlement, component, signing, or deployment requirements. The precise event where allow/deny takes effect, and the caller, file-object, and request identity available there, including an already-open descriptor. Whether authorization remains revocable after an allow response and before execution. If any timing guarantee is offered, its exact interval, assumptions, and documented bound. Whether denial, an enforcement timeout, or loss of the enforcing component prevents this request's synchronization work, or can occur after that work has started. We distinguish request admission, filesystem execution, return, and persistence completion. We do not assume that an earlier authorization marker is the execution boundary. We are asking about work attributable to this request, not unrelated background writeback, and are not asking for a bound on completion of an already-started fsync. We will separately evaluate how any documented platform guarantees can be bound to our application's authority and lifetime rules. If no supported interface provides the stated control on this configuration, please confirm that scope. If a route requires a different OS version, executable, filesystem, or deployment policy, please identify that change explicitly. This is an API/support-scope question; no proprietary source code or project archive is attached.

I’m looking for the documented Security.framework/macOS contract for this exact same-process sequence. An app creates a P-256 private key with SecKeyCreateRandomKey using: kSecAttrKeyType = kSecAttrKeyTypeECSECPrimeRandom kSecAttrKeySizeInBits = 256 kSecAttrTokenID = kSecAttrTokenIDSecureEnclave and, within kSecPrivateKeyAttrs: kSecAttrIsPermanent = true kSecAttrApplicationTag = <a unique tag> The app keeps the SecKeyRef returned directly by SecKeyCreateRandomKey alive and copies the corresponding public key with SecKeyCopyPublicKey. The app calls SecItemDelete with a query that uniquely matches that exact keychain item, and SecItemDelete returns errSecSuccess. Immediately after SecItemDelete returns, in the same process and without releasing or reacquiring the private-key reference, the app attempts a private-key operation using that same creation-returned SecKeyRef. Does errSecSuccess contractually guarantee that the already-retained SecKeyRef can no longer perform private-key operations from the point SecItemDelete returns? More concretely, is the following outcome forbidden by the API/platform contract: SecKeyCreateSignature succeeds after deletion, and the resulting signature verifies with the public key copied before deletion—that is, the public key from the same generated key pair? Or is invalidation of an already-issued SecKeyRef unspecified or otherwise not guaranteed by Security.framework? I’m asking only about the immediate post-return usability of the creation-returned SecKeyRef in this exact sequence. A clarification from Apple staff distinguishing the supported API/platform contract from current implementation behavior would be especially helpful.

I’m looking for clarification on supported public API semantics on macOS. Target runtime: arm64 macOS 15.4.1 build 24E263 The question is whether macOS provides a supported public API, or a supported composition of public APIs, that allows an external launcher or OS observer to: Obtain and freeze an identifier I(P) for the exact post-exec occurrence of a process P before P sends a security-sensitive IPC request. Later obtain OS-supplied sender identity J(M) for an individual XPC or raw Mach message M. Determine, using documented comparison semantics, whether J(M) identifies the same process-image occurrence as I(P). The comparison needs to distinguish cases such as: two concurrent processes with the same UID and signed code; exec replacement while retaining a PID; exit, restart, and PID reuse; stale or queued messages; a transferred XPC endpoint or Mach send right; an undelegated proxy. PID, UID, code-signing identity, launch labels, connection/right possession, or “first message wins” are not sufficient by themselves for this requirement. I have looked at mechanisms including: suspended process launch; task identity tokens; Endpoint Security AUTH_EXEC process identity; XPC per-message sender identity; SecCodeCreateWithXPCMessage; Mach audit trailers. What I have not found is public documentation defining a common process-occurrence identity and a supported comparison procedure across the pre-IPC and later message-sender surfaces. A token generated by the target and sent in its first message also would not solve this specific problem, because the process claiming the token has already selected itself before the external observer binds the expected occurrence. Is there a supported public way to achieve this? If so, I would appreciate pointers to: the relevant public APIs; the canonical comparison procedure; required entitlements, task rights, TCC permissions, root privileges, or system-extension requirements; documented behavior across exec, exit, restart, and PID reuse; relevant Apple documentation or sample code. If there is no supported public API that provides this property, confirmation of that would also be very helpful. I’m specifically interested in documented, supported public API semantics rather than private SPI or undocumented implementation behavior.