You can do this on basically any modern unix by passing file descriptors over a unix socket: the “graphical editor” server would launch as a user that can’t access anything except a socket and then users would open files by pushing an open fd to the editor over its socket.
This sounds interesting but I don’t understand what the underlying mechanism is. For me, a file descriptor is just an int corresponding to something I can read from and write to and a socket just carries bytes. I don’t understand how an FD can be sent over a socket or, if it can, how that’s anything more than just sending an int?
SCM_RIGHTS
Send or receive a set of open file descriptors from another process. The data
portion contains an integer array of the file descriptors. The passed file
descriptors behave as though they have been created with dup(2).
There are few interesting uses like for example, if you want to restart a network server, the old process can send its open, listening socket to the new process and thus achieve seamless switchover.
Other nifty thing with UNIX sockets is that you can just... read which user sent the message and as it is kernel adding that metadata you're 100% sure it came from that user. That's for example how you can set postgresql so say a certain user in the system can log as themselves without having to have a password.
In addition to sending data, processes may send file descriptors across a Unix domain socket connection using the sendmsg() and recvmsg() system calls. This allows the sending processes to grant the receiving process access to a file descriptor for which the receiving process otherwise does not have access.[2][3] This can be used to implement a rudimentary form of capability-based security.
I’m not exactly sure of the terminology, but there’s an opaque object corresponding to the int that can be passed between processes via unix sockets. I believe nginx and other web servers do this to transfer open connections to the new server process on restart without interruption.
You can express most of this using the existing capabilities in linux, the issue is that the interfaces you use to do stuff need to change in order to actually make it usable (as opposed to just instantly disabled as soon as it becomes a problem, like apparmor).
While true and actually pretty cool, a comment like this is a pretty good explanation of why we haven’t had widespread adoption of Linux on the desktop. I can imagine the users’ eyes glazing over.
