[HN Gopher] Whatever Happened to Sandboxfs?
       ___________________________________________________________________
        
       Whatever Happened to Sandboxfs?
        
       Author : zdw
       Score  : 71 points
       Date   : 2025-06-11 16:37 UTC (3 days ago)
        
 (HTM) web link (blogsystem5.substack.com)
 (TXT) w3m dump (blogsystem5.substack.com)
        
       | dangoodmanUT wrote:
       | 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 wrote:
         | 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 wrote:
           | No idea if this will be of any help but with a little
           | research found this on the docs https://developer.apple.com/d
           | ocumentation/virtualization/run...
           | 
           | there's also osx-kvm (non-apple)
           | https://github.com/kholia/OSX-KVM
        
       | comex wrote:
       | 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.
        
       | o11c wrote:
       | 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 wrote:
         | > 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 wrote:
           | Rust, OCaml and Haskell (ghc) do dynamically links against
           | libc by default, though. What they "statically link" is their
           | own libraries.
        
       | ajb wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-06-14 23:01 UTC)