1. 19

  2. 3

    There was a recent discussion about whether file-based APIs were better or worse the specific ones (https://lobste.rs/s/ckqzbn/why_filesystems_have_loose_coupling_your).

    I think a lot of the pros and cons of that API choice are illuminated by unveil.

    Things can always be implemented either way (layered on top of the generic mechanism, or given their own specific mechanism). But if you then enhance the general mechanism with a new feature, you get to use that for all of the functionality you have layered on top.

    (As a side thought - it’s kind of a nice thought experiment: If the only syscalls were open/close/read/write and friends - how would you (a) provide an interface for all other system calls and (b) put them together in a filepath hierarchy so that unveil() grouped things nicely.)

    1. 4

      I know very little about either of these topics, but I wonder if it would be interesting to combine OpenBSD’s security syscalls like pledge and unveil (is there a generic name for these? Privilege-based security?) with Plan 9’s extreme everything is a filesystem approach.

      1. 5

        The amount of syscalls in Plan9 is so small that pledge(2) wouldn’t make much sense. And unveil(2) wouldn’t really be necessary as there are already mount namespaces, a process can unmount paths and then use rfork(2)s RFNOMNT flag to disallow mounting new resources.


        1. 3

          In other words, Plan 9 obviated the need for these approaches. It really was the wave of the future, but it hasn’t reached the shore yet. Yet …