I'm working on a build system similar to Bazel where each build action runs in a sandbox. The sandbox contains only the files that the user defined as input to ensure that the build action doesn't have any implicit dependencies. Bazel achieves this by creating a "symlink forest" to the original source files. This works, but I have observed fseventsd using significant CPU during a Bazel build, presumably because of all the symlinks that get created.
Is there a way to disable file events for a directory or a volume? The "File System Events Programming Guide" in the Documentation Archive mentions placing an empty file named no_log in the .fseventsd directory at the root of the volume, but when testing on macOS 15.5 with APFS that appears to no longer work.
Related, is a "symlink forest" the best way to create a sandbox like this? Or is there a different method one can use to provide a view of a subset of the files in a directory tree? I read up on the App Sandbox but that seems too coarse grained. Something like Linux's overlayfs would work well, and maybe one can achieve a similar functionality with firmlinks? Curious about folks thoughts here.
Thanks in advance!
Is there a way to disable file events for a directory or a volume? The "File System Events Programming Guide" in the Documentation Archive mentions placing an empty file named no_log in the .fseventsd directory at the root of the volume, but when testing on macOS 15.5 with APFS that appears to no longer work.
Where you testing this on the boot volume? In theory I'd expect this to work, however:
-
I'm not sure we'd actually let you opt the boot volume out of fsevents.
-
Even if we did, I wouldn't be surprised if the entanglement between the ROSV (Read Only System Volume) and the writable data volume would end up leaving the fsevents system a bit... confused about what location it was supposed to check for that state.
-
Lastly, putting all other issues as side, opting "general"* user volumes out of fsevents is not some I'd recommend.
*As opposed to a "dedicated" volume that was specifically setup to serve a particular role.
One quick comment here:
maybe one can achieve a similar functionality with firmlinks?
Firmlinks are off the table. They're an "odd" structure we created as a solution to a very specific and narrow problem. They're NOT intended for "general" use and I wouldn't expect things to go well if you tried.
Related, is a "symlink forest" the best way to create a sandbox like this? Or is there a different method one can use to provide a view of a subset of the files in a directory tree? I read up on the App Sandbox but that seems too coarse grained. Something like Linux's overlayfs would work well, and maybe one can achieve a similar functionality with firmlinks? Curious about folks thoughts here.
Well, my initial thought would be to use disk images*. That creates an entirely isolated file system environment which you can quickly destroy with minimal effort. Depending on your larger hardening goals, you could actually create a dedicated build system user and then architect your posix permissions such that the ONLY location it has write access to is that volume.
*I haven't tested if the "no_log" file works in a disk image, but if it doesn't please file a bug, post the bug number back here, and then I'll track down what you need to do instead.
Depending on how far you want to take that approach:
Related, is a "symlink forest" the best way to create a sandbox like this?
...you could actually use the disk image itself as the "entire" solution. That is, you design your system such that "everything" is stored inside a Disk Image. Normal work modifies that image and to build the (basic) flow would be the following:
- Unmount the working image (so that everything flushes to disk).
- Duplicate the working image (on APFS, this is a single file clone which is effectively "instantaneous" regardless of file size).
- Mount the new duplicate.
- Run the build process inside that newly created duplicate.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
