We need a documented interface/access contract for a test supervisor that requires a bounded, process-birth-bound census of every process with its effective UID and every current vnode descriptor of those processes. Coverage includes ambient same-UID processes and descriptors opened before observation starts. The census needs vnode identity, type, ownership, mode, link count and open flags. Unavailable metadata is a refusal; we cannot treat EPERM as absence or exempt a process or descriptor. This is a cooperative same-user lifetime-containment check. We do not require file contents or an atomic global snapshot.
Environment of the retained observation: Apple Silicon, macOS 27.3 (26C5035r), Darwin 27.3.0; Xcode 27.0 (27A5194q), macOS 27.0 SDK.
The subject was the system LaunchServices process /usr/libexec/lsd. Caller real/effective UID matched the subject's UID/RUID/SVUID. Before/after process identity, version, start time, credentials and executable-path samples matched. PROC_PIDLISTFDS returned 32 bytes and listed FD 3 as PROX_FDTYPE_VNODE. The following call shape returned 0 bytes with errno == EPERM (1), with 176 bytes expected in that environment:
struct vnode_fdinfo info = {0};
errno = 0;
int count = proc_pidfdinfo(pid, fd, PROC_PIDFDVNODEINFO,
&info, sizeof(info));
int saved_errno = errno;
Errno was cleared before and saved immediately after the call. Credentials were not modified. The matching process bracket does not establish an FD-to-path association or a specific protection category. In particular, we have not established a Data Vault subtype.
Questions:
- Is there a supported public interface or provisionable entitlement that supplies the required metadata for every current same-UID vnode descriptor, including descriptors whose metadata is protected internally by macOS?
- If Endpoint Security is the supported route, which documented API supplies a complete current FD inventory and vnode mapping, including already-open descriptors and ambient same-UID processes? A solution limited to descendants of the client does not cover this requirement.
- If supported interfaces cannot guarantee that coverage, could you clarify the limitation? Is there a supported diagnostic that identifies the protection category responsible for this metadata denial without inspecting private policy state?
I have considered the "On File System Permissions" guidance, including its mandatory-access-control and Endpoint Security discussion:
https://developer.apple.com/forums/thread/678819
This post describes a retained observation, not a new reproduction or qualification result. All retained results remain UNPROVED. A focused SDK/libproc Xcode example was previously built for arm64 and x86_64 but was not run; it illustrates the call sequence and a BSD start/credential bracket, not complete kernel birth binding or the required census. It does not guarantee reproduction on another system. The sanitized supporting record and example are already attached to the private DTS request that directed me to the forums. Please advise the supported interface/access contract, or its limitation, and any further diagnostic scope needed.
