4 ms·

This design is so thoughtful. Thanks to fork, you can easily sandbox a child process to a specific subtree of the filesystem: fork, unveil(0, 0), run untrusted

• malkia 8y ago
  Build systems can use such feature, without going through heavy duty isolation (sandboxing) like Bazel. It's done there, such that "accidental" dependencies are not followed, e.g. if your a.cpp source included b.h it better be that the rule compiling a.cpp explicitly stated that is dependent on a rule "exporting" b.h And possibly for other uses too :)
• saagarjha 8y ago
  Is sandboxing on macOS not exactly this (albeit with a different API)?
  • floatboth 8y ago
    It is. You have to write the rules as a Lisp script, and there's a scary "this is sort of deprecated, use the new Mac App Store stuff" paragraph in the manpage, but yes, it does allow exactly that.
• geocar 8y ago
  Can you? I haven't used OpenBSD in around fifteen years. Is the dynamic linker somehow exempt from unveil? Or does it somehow know what's going on?
• patrec 8y ago
  I wish instead of a patchwork of hacks like this we had a nice fundamental mechanism, e.g. capabilities exposed via a union file system (i.e. you make everything your process might want to access available via a file handle and run it in some chroot where you "mounted in" the things you want it to be able to touch; e.g. /bin has all the programs it can run, network, window manager and process tree access is mapped to /net /x and /proc etc).