Post

Replies

Boosts

Views

Activity

Reply to request for a kernel I/O passthrough API for file-backed volumes (FUSE_PASSTHROUGH / ProjFS equivalent)
Thanks Kevin, that's fair for a stable hierarchy, but it doesn't really hold for this workload. The clone/disk-image approach assumes the input set is something you provision once and then snapshot per action. Bazel's isn't. The files I project live in output_base (external repo cache, bazel-out, action outputs), which is rewritten constantly across and within builds — so there's nothing stable to clone, and an image you have to unmount to clone cheaply is a non-starter when it's written on basically every action. The inputs are also spread across multiple volumes, and clonefile is same-volume only, so the cross-volume case can't clone at all — you'd have to first copy everything into one place, which reintroduces the per-action materialization cost (over a moving target) that passthrough is meant to avoid. On EndpointSecurity — interesting pattern, and I see the appeal over sandbox-exec, but it's the same model: observe an access and allow/deny it. Bazel's sandbox is already built on sandbox-exec. The job here isn't to catch a tool reading something it shouldn't — it's to present a namespace where the undeclared files just don't exist. clang, node, rollup etc. constantly read things they never declared (implicit includes, module resolution walking parent dirs); that's normal, not misbehavior to deny, and a denied open is an error, not a redirect — it breaks the tool instead of steering it. ES also can't fix readdir: anything that globs or walks a dir still sees undeclared entries even if the later open is denied, because ES/sandbox-exec sit on top of the real tree. The symlink case is the concrete failure: the sandbox today is symlinks into the real tree, and Node realpath()s as it resolves modules, so it follows the link out of the sandbox and walks node_modules up the real parent chain, reading packages that were never declared. To a deny-layer that isn't even a violation — the resolved path is a legitimate file. It's just normal realpath semantics, which is exactly why authorization can't catch it. So ES is mostly an alternate sandbox-exec with an auth round-trip per op, and it leaves the same leaks. Projection changes what exists rather than punishing the tool for looking, which is what makes it both correct and able to steer at runtime — and that's the thing the passthrough primitive would make practical.
Topic: App & System Services SubTopic: Core OS Tags:
2w
Reply to Is inode invalidation currently supported?
I just checked the macos 27 beta, it seems like the invalidation mechanism has been built into the lifs/fskit
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
2w
Reply to request for a kernel I/O passthrough API for file-backed volumes (FUSE_PASSTHROUGH / ProjFS equivalent)
Thanks Kevin, that's fair for a stable hierarchy, but it doesn't really hold for this workload. The clone/disk-image approach assumes the input set is something you provision once and then snapshot per action. Bazel's isn't. The files I project live in output_base (external repo cache, bazel-out, action outputs), which is rewritten constantly across and within builds — so there's nothing stable to clone, and an image you have to unmount to clone cheaply is a non-starter when it's written on basically every action. The inputs are also spread across multiple volumes, and clonefile is same-volume only, so the cross-volume case can't clone at all — you'd have to first copy everything into one place, which reintroduces the per-action materialization cost (over a moving target) that passthrough is meant to avoid. On EndpointSecurity — interesting pattern, and I see the appeal over sandbox-exec, but it's the same model: observe an access and allow/deny it. Bazel's sandbox is already built on sandbox-exec. The job here isn't to catch a tool reading something it shouldn't — it's to present a namespace where the undeclared files just don't exist. clang, node, rollup etc. constantly read things they never declared (implicit includes, module resolution walking parent dirs); that's normal, not misbehavior to deny, and a denied open is an error, not a redirect — it breaks the tool instead of steering it. ES also can't fix readdir: anything that globs or walks a dir still sees undeclared entries even if the later open is denied, because ES/sandbox-exec sit on top of the real tree. The symlink case is the concrete failure: the sandbox today is symlinks into the real tree, and Node realpath()s as it resolves modules, so it follows the link out of the sandbox and walks node_modules up the real parent chain, reading packages that were never declared. To a deny-layer that isn't even a violation — the resolved path is a legitimate file. It's just normal realpath semantics, which is exactly why authorization can't catch it. So ES is mostly an alternate sandbox-exec with an auth round-trip per op, and it leaves the same leaks. Projection changes what exists rather than punishing the tool for looking, which is what makes it both correct and able to steer at runtime — and that's the thing the passthrough primitive would make practical.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
2w
Reply to request for a kernel I/O passthrough API for file-backed volumes (FUSE_PASSTHROUGH / ProjFS equivalent)
This also will help with executable binary performance on these mounts where AMFI wants to read the executables and verify their signatures, such api will probably allow AMFI to see that these vnodes are basically aliases and hopefully skip the validation? On workloads such as Bazel, AMFI serializes the sandboxed actions.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
3w
Reply to request for a kernel I/O passthrough API for file-backed volumes (FUSE_PASSTHROUGH / ProjFS equivalent)
I sent the feedback request a while back; its FB22596726 I was just hoping i could talk to the FSKit/lifs engineers directly for feasibility of this and how much it would actually help.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
3w
Reply to Apple API for user-space filesystems?
I don't think system extensions are the answer here.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
May ’24