Hacker News Reader

Comment by Someone | Hacker News Reader

> You might want to allow graphical editor to open any graphical file, regardless of location.

More likely, you want to temporarily give them permission to specific files you indicate. A graphical editor doesn’t have reason to read any file that the user didn’t explicitly picked for editing/viewing.

That’s how Mac OS works nowadays (possibly except for the ‘temporarily’; I don’t know the details): applications can only open files that the user selected in the system file open dialog. That runs in a separate process and opens up an app’s sandbox to allow access to the file the user selected.

View on HN

That limits your application though. It means you have to use the system file picker. For many apps that might be fine. But it means you can't have something like vim or emacs where you open files with a command. Or have an option that does something like open a sibling .h file when you are editing a .c file. Or search up the directory to find the applicable .editorconfig file.

So why does it work for Mac, Android, and iOS?

Well, the examples given don't, generally speaking. For stuff like compiling you can do things like have the permission apply to an entire folder, though.

In fact, it doesn't work. Both Android and macOS apps will commonly ask for "full filesystem access" permissions for this exact purpose, which sort of defeats the point (for those apps at least). I don't use iOS enough to speak to how this is handled there, but the few times I've had to wrangle some files on there it made me want to smash my head into the wall.

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.

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.

I wouldn’t tell a user this, but developers of the desktop environments and distributions are leaving a lot of the design space unexplored.

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?

https://en.wikipedia.org/wiki/Unix_domain_socket

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.

Ancillary data: https://linux.die.net/man/3/cmsg

It's special API that tells kernel to duplicate FD and give it to different process.

https://linux.die.net/man/7/unix

    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.

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).

Flatpak [1] offers something similar on Linux:

> The FileChooser portal allows sandboxed applications to ask the user for access to files outside the sandbox. The portal backend will present the user with a file chooser dialog.

> The selected files will be made accessible to the application via the document portal, and the returned URI will point into the document portal fuse filesystem in /run/user/$UID/doc/.

[1]: https://docs.flatpak.org/en/latest/portal-api-reference.html...

Reply on news.ycombinator.com