1. 19
  1.  

  2. 3

    For someone who has no direct experience using Plan9, what is security like in this world of being able to import anyone’s network stack?

    1. 7

      I just asked Ron Minnich, a Harvey OS dev, about your question. This is his answer: “The security is actually very good, quite a long way ahead of Unix. You can’t import a network stack unless you have authenticated yourself to that machine, and the owner of that network stack is satisfied as to your identity and access rights [i.e. Authentication and Authorization are separate]. Authentication is managed by an authentication server. There’s a lot more to this process than I can go into here, but this talk is a pretty good summary: https://swtch.com/~rsc/talks/nauth.pdf Note that one of the authors, Eric Grosse, has been a security VP at Google for some team. These folks know their stuff. Oh, and on Plan 9, servers run as none: breaking a server gives you hardly any access”

      1. 3

        Probably not that different from the world of being able to run networking code on anyone’s machines.

        1. 1

          Can you be more precise in your answer? The example given is something like import somplace_else /net /net. That seems rather different than the current state of affairs. Not that the current state of affairs are great.

          1. 3

            What I mean is that it’s not too different from ssh someplace_else. Both require authentication and authorization (so “anyone” is a very restricted group), both let you send packets from the someplace_else’s IP address and use its other resources (in case of ssh, by running code on the server). Of course, as @unbalancedparentheses mentions, the details of Unix’s and Plan 9’s security policies differ, but the idea of sharing a machine’s resources over the network is not new — in fact, this is what networks are about.

      2. 1

        I’m not very familiar with Plan9’s distributed filesystems, but the part below sounds a lot like what Linux users do with FUSE filesystems such as sshfs,

        Plan 9 supports the idea of location transparency, in which resources can be accessed without regard to where they might be. One can mount resources from 9p servers anywhere into a namespace, and from that point on, they appear to be local. This changes your life; you never need to use scp again, and you never need to think about how to get to your files.

        I gather the main difference with Plan9 is that this is all done through a more pervasive and unified model? FUSE is obviously specific to filesystems; you can’t mount a network stack with it.

        1. 4

          Plan9 lets you do some more tricks too, like for example binding more drives/paths to the same folder.. it seems crazy, but that’s how they get away with having no PATH env variable. The shellscript that sets up a terminal simply “binds” all bin directories to /bin, and the shell just tries to find executables from there.

          1. 1

            That’s fascinating. I suppose /bin is marked as read-only then, or are you allowed to write files to /bin too?

            1. 3

              If I’m reading the bind(1) manual page correctly, the resolution of where to create the file depends on two things: 1) bound directories have a precedence order (the -a and -b options control whether bind(1) adds to the front or end of the list), and 2) bound directories can be mounted with or without the -c (file creation permitted) flag. Attempts to create a new file at a given path get passed through to the highest-precedence directory that was bound with -c (if any were).

              Here’s the -c flag’s description from the manpage:

              This can be used in addition to any of the above to permit creation in a union directory. When a new file is created in a union directory, it is placed in the first element of the union that has been bound or mounted with the -c flag. If that directory does not have write permission, the create fails.

              1. 2

                I haven’t tried that, but I suppose you can write files to /bin.. they’d just stay in /bin.

                There’s also the fact that the rc shell is quite clever and lets you do subdirectory bins.. like you can make a path like /bin/mycollection/mytool and call it from the terminal by using:

                # mycollection/mytool
                

                One example might be the “ip” directory that contains ipconfig and some other network related tools.

            2. 1

              sounds a lot like what Linux users do with FUSE filesystems such as sshfs,

              Filesystem sharing exists on Unix since NFS. (Or does sshfs do more than that?)

              I gather the main difference with Plan9 is that this is all done through a more pervasive and unified model?

              Yes, basically: in Plan 9 the idea that “everything is a file” is more pervasive than in Unix, even after the latter stole /proc from the former. Also, export in 9P is more granular (can export individual files), transitive (reëxport of imported resources possible) and bidirectional (when you connect to a “cpu server”, your workstation exports keyboard, mouse and screen file descriptors (which are themselves multiplexed by the window system)).

              FUSE is obviously specific to filesystems; you can’t mount a network stack with it.

              But can’t you, at least in theory, create a FUSE filesystem that will give you network sockets when open(2) is called on its entries?

              1. 1

                Filesystem sharing exists on Unix since NFS. (Or does sshfs do more than that?)

                It seemed relevant to me mostly because of the comment about scp. Sshfs lets a user with no privileges mount any remote filesystem they have access to over ssh, so anything that can be scp’d can also be mounted. Whereas NFS only lets you mount filesystems that the administrator of the remote machine has explicitly chosen to export over NFS.

                1. 1

                  But can’t you, at least in theory, create a FUSE filesystem that will give you network sockets when open(2) is called on its entries?

                  Sure. I mean, people build FUSE layers for random APIs (here is a Neovim API in FUSE: https://github.com/fmoralesc/nvimfs)