Auto-connection request for system-files on lens-for-gnome

store-requests privileged-interfaces
1

Hello team, I am requesting auto-connection for system-files capability for my Applauncher (Spotlight alike alternative for Gnome) Thank you in advance.

name: lens-for-gnome

description: AI-assisted local desktop search engine

snapcraft: https://snapcraft.io/lens-for-gnome

upstream: GitHub - cwittenberg/lens-for-gnome: Spotlight alike local AI search for Gnome · GitHub

upstream-relation: Publisher & Author

interfaces:

system-files:

request-type: auto-connection

reasoning: Lens for GNOME includes an Application Launcher plugin. In order to discover and launch other Snap-packaged applications on the user’s system, the search engine legitimately needs read-only access to /var/lib/snapd/desktop/applications to parse the .desktop files.

2

This request has been added to the queue for review by the @reviewers team.

3

Hey @cwittenberg

Lens for GNOME includes an Application Launcher plugin. In order to discover and launch other Snap-packaged applications on the user’s system, the search engine legitimately needs read-only access to /var/lib/snapd/desktop/applications to parse the .desktop files.

I wonder how read access to /var/lib/snapd/desktop/applications is enough to launch the applications properly. Could you please provide more details, I think I’m possibly missing something

4

Hi jslarraz,

Thanks for asking the question, sharp. You are completely correct that a strictly confined snap cannot execute bins outside.

Lens for GNOME operates in two interconnected parts: a strictly confined Rust daemon (the search engine, this application) and a GNOME Shell extension (the UI, part of extension store here https://extensions.gnome.org/extension/10337/lens/)

The strictly confined daemon only uses the requested read access to /var/lib/snapd/desktop/applications to index the application names, icons, and Exec strings to populate the user’s search results.

When a user actually clicks an application to launch it, the strict daemon does not attempt to execute the binary itself. Instead, the daemon passes the .desktop file path back to the Lens GNOME Shell extension via an IPC payload.

Since the extension runs natively within the GNOME Shell process, it uses standard host privileges (Gio.DesktopAppInfo.new_from_filename()) to launch the application cleanly - on behalf of the user, or so is the plan - once this privilege has been approved.

Let me know if you need any further technical details about the IPC delegation. Source code is here should you want to review the interplay: GitHub - cwittenberg/lens-for-gnome: Spotlight alike local AI search for Gnome · GitHub

Cheers, Christian.

5

Thanks for the info, I think this sounds reasonable to me. @pedronis any objection given that it affects /var/lib/snapd?

6

@jslarraz Any update on this perhaps? Would like to move forward. It’s just read-only authorization to read the .Desktop files. Many thanks

7

@pedronis @jslarraz Must be the holiday period - but it’s been nearly two weeks, would you kindly have a look at my request to have this enabled? Many thanks. Cheers, Christian.