Does FSKit support the ability to get the process information, such as the pid, when a process accesses a resource?
Being able have the process context is important for implementing certain access patterns and security logging in some contexts.
For instance, we have a system that utilizes (pre-FSKit) a FUSE mount that, depending on the process has different "views" and "access" based on the process id.
Did a bit more browsing and found the answer as of June '25: No, process attribution is not supported yet.
I will pop up a enhancement request.
For posterity: The reason why process attribution is a good feature is to help support workflows for isolated filesystems like the spk/spfs project:
The Software Platform FileSystem (SPFS) is a tool for isolating, capturing and distributing software runtime environments. In many ways, what it provides is like a lightweight container combined with the functionality of git. SPFS delivers some of the benefits of a container runtime without creating too much isolation from the host environment.
I tested this against Xcode 27 beta 3 and the macOS 27 SDK. The new handler-style FSKit API gets close, but FSContext currently exposes only the caller’s real/ effective UID and GID.
For a process-scoped Nix store, two processes owned by the same user may need to see different store paths. Visibility is determined by a selected process and its descendants, so the filesystem needs a stable PID, audit token, or equivalent per- process identity. UID/GID alone isn’t sufficient.
Because /nix/store objects are immutable, file-data cache coherency isn’t a concern. The remaining caching question is namespace visibility: can positive or negative lookup results and vnodes be reused across callers without invoking the context-aware FSKit handler?
For example, one process may resolve /nix/store/X, while another same-UID process should receive ENOENT. A cached positive or negative lookup must not leak between those views.
Could Apple clarify:
Is there a public way to obtain the initiating process identity or audit token from FSContext?
When lookup results depend on FSContext, does FSKit guarantee that the handler is invoked for each caller despite name/vnode caching?
If the second guarantee already exists, process identity may be the only missing capability. Otherwise, this use case would also need caller-scoped namespace caching or a way to disable positive and negative lookup caching.
FSContext. Our Security teams have not approved this functionality.Thank you for explaining what you want to do. I now can respond to what I gathered you are doing.
It sounds like you are describing functionality akin to Linux Namespaces. It is a system-wide feature. All of macOS would need to participate in supporting it.
On macOS now, applications use XPC services to split processing up across helper services. These helpers run in their own processes. An example I keep in mind is archive extraction. Archive processing frameworks can farm operations out to helper services (processes), so that a malformed archive can only attack the extractor. It can not attack the application (web browser?) desiring the extraction. That service would need to be aware of and propagate the namespace of the application requesting the service.
I mention this disparate functionality to hi light that supporting the feature you want to give your customers needs more than for FSKit to give your process a PID.