Skip to content(if available)orjump to list(if available)

Whatever Happened to Sandboxfs?

Whatever Happened to Sandboxfs?

8 comments

·June 11, 2025

comex

Recently, macOS added a built-in FUSE-like API:

https://developer.apple.com/documentation/fskit

No idea what the performance is like.

However, over the last few years, Apple’s compilers have gotten even more enthusiastic than before about caching and “content addressable storage”:

https://llvm.org/devmtg/2024-10/slides/techtalk/Rastogi-Fine...

Which is normally a good thing, but may exacerbate the issue described in the post where, by enforcing isolation, you end up cutting off the compiler from its caches and making the build slower.

I think the ideal solution would be for Bazel to somehow know about and integrate with LLVM’s CAS.

edit: although just figuring out how to do “explicit module builds” with Swift and Clang would probably get you most of the way.

ajb

It's amazing that the conclusion it's that sandboxing would have had to use NFS, which is the approach that the vesta build system took 20 years earlier.

dangoodmanUT

Seems like the new ASIF sparse image format will solve a lot of this, combined with their new containerization framework

https://eclecticlight.co/2025/06/12/macos-tahoe-brings-a-new...

jitl

Copying data into and out of a disk image is probably going to be much slower and involve just as many syscalls if not more compared to setting up a “symlink forest”.

As far as I can tell, the containerization framework seems like it’s for running Linux microvms, and doesn’t seem applicable to people trying to do macOS builds. I mean, if you just want to run Bazel in a Linux VM sure it will do fine, but you can already run Bazel in a Linux vm on your Mac with Docker.app. Maybe I missed something with the containerization docs but all I saw was EXT4, OCI Linux images, etc. no Mac thingies.

tough

No idea if this will be of any help but with a little research found this on the docs https://developer.apple.com/documentation/virtualization/run...

there's also osx-kvm (non-apple) https://github.com/kholia/OSX-KVM

o11c

If you semi-trust your tool binaries enough not to do something silly like making syscalls directly, what about using the `LD_PRELOAD` equivalent to intercept `open` etc.? (Yes there's a long tail in that "etc.")

Or does using Go ruin everything again?

(Also it seems like it should in principle be possible to keep the symlink forest around and only delete other files)

eru

> Or does using Go ruin everything again?

Go isn't the only language ecosystem that likes to make statically linked binaries. Rust, OCaml and Haskell etc also prefer this.

Or am I missing something?

I think dynamic linking is mainly popular in the C (and perhaps C++) world? And I guess for commonly interpreted languages like Python, more or less.

_flux

Rust, OCaml and Haskell (ghc) do dynamically links against libc by default, though. What they "statically link" is their own libraries.