7 ms·
Only sounds like "irony" if you don't understand problem. The problem is not isolation or lack of it. The problem is that app require complex set of permission
by ilyt 3y ago
Only sounds like "irony" if you don't understand problem.
The problem is not isolation or lack of it. The problem is that app require complex set of permissions for both users files and other apps.
App might want to send notification to notification daemon. But app should not be able to pretend to be another app, whether by name or icon. And good luck trying to stop malicious app from just making same/similar enough icon and spelling Firefox with some fancy UTF characters to go around it.
And that's pretty simple case! And already very hard on kernel/OS level to solve. Now look at files.
You might want to allow graphical editor to open any graphical file, regardless of location.
You might want to allow that same editor to only edit some of them.
But for browser, you might want to allow saving new files, but not editing/rewriting existing ones, because it is not an editor, and should have no business editing the files.
Or, allow browser tab browsing certain URL (say, web image editor) to modify the files, but not the image sharing webpage that only needs to read the file.
Now we not only have insanely granular permissions per app, the different actions from "app" (web browser is basically container for multiple applications at that point) also need different permissions.
It has nothing to do with "unix bad", or "unix wrong", to actually separate the applications without hardships on the user (like fucking with permissions every time one app needs to touch files of another app) is just very very hard
- Someone 3y ago> 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.
- fiddlerwoaroof 3y agoYou 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.
- labster 3y agoWhile 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.
- fiddlerwoaroof 3y agoI wouldn’t tell a user this, but developers of the desktop environments and distributions are leaving a lot of the design space unexplored.
- gorgoiler 3y agoThis 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?
- wruza 3y agohttps://en.wikipedia.org/wiki/Unix_domain_socket 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.
- fiddlerwoaroof 3y agoI’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.
- azlev 3y agoAncillary data: https://linux.die.net/man/3/cmsg https://linux.die.net/man/3/cmsg
- thayne 3y agoThat 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.
- flangola7 3y agoSo why does it work for Mac, Android, and iOS?
- rcxdude 3y agoWell, 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.
- franga2000 3y agoIn 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.
- ciupicri 3y agoFlatpak [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#gdbus-org.freedesktop.portal.FileChooser https://docs.flatpak.org/en/latest/portal-api-reference.html...
- deleted 3y ago[deleted]