Request for auto connection to plug dot-local-share-applications

[soumyaDghosh]

Request to autoconnect to the plug dot-local-share-applications to allow the read access to .local/share/applications. Without this connection, there will always be a popup like this.

This is my declaration in snap manifest

plugs:
  dot-local-share-applications:
    interface: personal-files
    read:
      - $HOME/.local/share/applications

My app doesn’t even access the home folder. Just this auto connection is needed to get rid of the popup. This is my source-code https://github.com/soumyaDghosh/menukaran

[cav]

hey @soumyaDghosh - can you give a bit more detail on how the snap uses this interface? Thanks!

[soumyaDghosh]

I use file-picker pub package from flutter and I added the .local/share/applications as the initial directory, so, that I can get the folder path selected by users via portals. This is the code block.

https://github.com/soumyaDghosh/menukaran/blob/main/lib/desktop_menu_page/create_desktop.dart#L209

When it opens up that folder, it first opens with the folder as it is, that’s why the permission-denied popup comes up. Just with read access to dot-local-share-applications I can fix it. I probably need to add the word application in the plugs.

[ogra]

This definitely sounds like a bug with the portal though, did you file it upstream yet ?

[soumyaDghosh]

Nope, I faced this problem sometimes ago with Tube Converter(now named Parabolic) also. Gtk.FIleDialog has an instance-method set_initial_folder. TC used it to save the last selected directory. Now, back then, TC snap didn’t have the access to home folder. So, I just disabled that feature for snap.

https://github.com/NickvisionApps/Parabolic/blob/main/NickvisionTubeConverter.GNOME/Views/AddDownloadDialog.cs#L485

[ogra]

Well, the portal should check for existence of the directory outside of confinement, this is what i think is the bug … there is a design flaw in the portal design here …

[soumyaDghosh]

Probably snap specific bug.

[ogra]

no, it is broken behavior of the portal (why would it try to look inside the confined space for a writable place)

[soumyaDghosh]

Should I look more about this, or I’ll be allowed this auto-connection for now?

[ogra]

you know I’m not a reviewer you got to wait for two reviewers to answer this one …

[soumyaDghosh]

made a silly question @reviewers pinging here for more info

[ogra]

FWIW i dont think read access to that dir would be a massive security risk, so if i was a reviewer I’d +1 the request

[cav]

+1 for auto-connecting read-access to dot-local-share for menukaran. Given the app deals with handling desktop files and portals behaving unexpectedly, an auto-connect to read this dir is not unexpected and this fits the purpose and functionality of the snap.

I do also agree with the update to the plug name you mentioned to change it to dot-local-share-applications.

[jamesh]

Looking at the code, it seems like you’re using this directory as the initial location for a save dialog:

https://github.com/soumyaDghosh/menukaran/blob/4a546b8a31e714da68e54f62143e155c3fd2592e/lib/desktop_menu_page/create_desktop.dart#L207-L211

That is going to be a bad experience if the app can’t actually write anything there.

And granting write access to this directory creates new security concerns. It would be trivial to use that access to escape the snap sandbox by e.g. writing a desktop file with the same name as a common app, and wait for the user to run it for you.

[soumyaDghosh]

@jamesh

That is going to be a bad experience if the app can’t actually write anything there.

And granting write access to this directory creates new security concerns. It would be trivial to use that access to escape the snap sandbox by e.g. writing a desktop file with the same name as a common app, and wait for the user to run it for you.

I just need read access not write, because the write access will be given to me by portals. I’ll not write to exactly $HOME/.local/share/applications, rather in a folder like /run/user/1000/doc/xxxx. That’s also why I’ve implemented SQL Db to manage the installed desktop files. Also my request specifically asks for read access everywhere, in the github repo, and in this post.

@soumyaDghosh

Request to autoconnect to the plug dot-local-share to allow the read access to .local/share/applications. Without this connection, there will always be a popup like this.

[soumyaDghosh]

Any update on this? @jamesh can you kindly look into this again?

[soumyaDghosh]

Pinging again. Any updates. @dclane can you look onto this? It’s been long now.

[James-Carroll]

@soumyaDghosh

I just need read access not write, because the write access will be given to me by portals

I must admit I’m confused, why can the portals grant write access but not read access? I’ve seen the portals muck about with ~/.SSH/ just fine, what are they actually failing to do here?

Is the problem you’re on an older version of the portals that cannot grant access to folders at all? (E.G Ubuntu 20.04).

@jamesh

It would be trivial to use that access to escape the snap sandbox by e.g. writing a desktop file with the same name as a common app, and wait for the user to run it for you.

It’s even quicker than relying on the user for that. You’d just write a custom protocol handler and then xdg-open it directly, the desktop plug autoconnects afterall. There’s no situation where write access to this folder is safe via anything other than trust in the publisher, and the only apps that have been given are heavily scrutinised browsers like Chromium, and Steam which is packaged by Canonical directly with the backing of a multi-billion corporation (Valve).

Like Ogra I’m not a reviewer and don’t see a problem with READ (not write) access to that folder intrinsically. But I don’t see how the personal-files interface comes into this at all yet, either the portals can do all of it or they can do none of it would be my assumption.

[soumyaDghosh]

@James-Carroll

I must admit I’m confused, why can the portals grant write access but not read access? I’ve seen the portals muck about with ~/.SSH/ just fine, what are they actually failing to do here?

Is the problem you’re on an older version of the portals that cannot grant access to folders at all? (E.G Ubuntu 20.04).

You probably didn’t read my above answers,

@soumyaDghosh

I use file-picker pub package from flutter and I added the .local/share/applications as the initial directory, so, that I can get the folder path selected by users via portals. This is the code block.

https://github.com/soumyaDghosh/menukaran/blob/main/lib/desktop_menu_page/create_desktop.dart#L209

When it opens up that folder, it first opens with the folder as it is, that’s why the permission-denied popup comes up. Just with read access to dot-local-share-applications I can fix it. I probably need to add the word application in the plugs.

This is probably a bug and, so, not my fault. I just want my users to have a good experience.

[James-Carroll]

But if the file-picker is showing permission denied, that means the file-picker is in the apparmour confinement for your snap, I.E, you’re not using the portals. The thing that makes most sense to me here is that your version of xdg-desktop-portals is older than 1.7, which introduces support for folders, since the portals couldn’t support directories before 1.7, it falls back to an in-process file picker running in the Snap confinement and not outside of it like we’d prefer. A portal before 1.7 would fail exactly how you describe.

https://github.com/flatpak/xdg-desktop-portal/releases/tag/1.7.0

This is why I asked are you on Ubuntu 20.04, because that wouldn’t have the directory support, but every supported release of Ubuntu afterwards should.

I’m not against the personal-files interface as you’ve asked for it, but I’d love to know if you had this same problem on a more recent distribution, or what distribution you’re having this problem on. It just helps set expectations in the future, and means we can justify the exception more clearly. At the moment it’s a weird behaviour that would be nice to be explained rather than just worked around.