7 ms·

> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to th

by hattar 20d ago

> Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents. What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)

NekkoDroid 20d ago
> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
- actionfromafar 20d ago
  It would not expose SSH keys, but the location of SSH keys.
  - wongarsu 20d ago
    And what is even the concern about that? I don't mind software knowing that my ssh key is in ~/.ssh/id_ed25519. Maybe if you see a 500 byte ~/.ssh/id_rsa that's an issue, but then the real issue is the tiny key Thinking about threat scenarios of directory structure access, I'd be much more concerned about exposing that I have ~/documents/work/mergers/2027/[secret]_WarnerBros-Fox.docx But only being able to see the file name would still be a huge improvement over being able to open the document and exfiltrate it
mike_hearn 20d ago
You don't get such prompts on macOS if the app uses the system file picker, which they nearly all do. You will get prompts for certain sub-directories of $HOME if the app directly opens them using POSIX or similar, so for example, anything running in a terminal emulator, or inside a virtual machine. Developers will see these prompts a lot more often than regular users do. MacOS doesn't let apps read directories but not files.
pinkwah 20d ago
macOS does this for select directories. You either give access to all of `Documents` or none. It's also not great for notification fatigue, as you get like 8 popups at once in iTerm2. If you choose not to give access to a directory, you'll need to go to system settings to change this. So, for a "better" system, we'd need to ask for every directory and you better hope the program doesn't try to glob all files in every directory and overload the user in prompts. Or you can "Allow all" or something, and then we're back at square one where the program has too much access.
j16sdiz 20d ago
The "open panel" in macOS is actually a system service, run out-of-process, with different sandbox and permission.
- fph 20d ago
  This is the sane solution. And not unlike what Android does in the end, with the difference that they have a share panel instead of an open panel: so you initiate the process from the app that owns the file rather than the one that wants to access it. But GUI apps on Linux are so fragmented that getting everyone to use the same open panel is hopeless.

by hattar 20d ago

NekkoDroid 20d ago

> What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative. Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).

actionfromafar 20d ago
It would not expose SSH keys, but the location of SSH keys.
- wongarsu 20d ago
  And what is even the concern about that? I don't mind software knowing that my ssh key is in ~/.ssh/id_ed25519. Maybe if you see a 500 byte ~/.ssh/id_rsa that's an issue, but then the real issue is the tiny key Thinking about threat scenarios of directory structure access, I'd be much more concerned about exposing that I have ~/documents/work/mergers/2027/[secret]_WarnerBros-Fox.docx But only being able to see the file name would still be a huge improvement over being able to open the document and exfiltrate it

mike_hearn 20d ago

You don't get such prompts on macOS if the app uses the system file picker, which they nearly all do. You will get prompts for certain sub-directories of $HOME if the app directly opens them using POSIX or similar, so for example, anything running in a terminal emulator, or inside a virtual machine. Developers will see these prompts a lot more often than regular users do. MacOS doesn't let apps read directories but not files.

pinkwah 20d ago

macOS does this for select directories. You either give access to all of `Documents` or none. It's also not great for notification fatigue, as you get like 8 popups at once in iTerm2. If you choose not to give access to a directory, you'll need to go to system settings to change this. So, for a "better" system, we'd need to ask for every directory and you better hope the program doesn't try to glob all files in every directory and overload the user in prompts. Or you can "Allow all" or something, and then we're back at square one where the program has too much access.

j16sdiz 20d ago

The "open panel" in macOS is actually a system service, run out-of-process, with different sandbox and permission.

fph 20d ago
This is the sane solution. And not unlike what Android does in the end, with the difference that they have a share panel instead of an open panel: so you initiate the process from the app that owns the file rather than the one that wants to access it. But GUI apps on Linux are so fragmented that getting everyone to use the same open panel is hopeless.