Privileged-interface review request for downman (personal-files ×4, shutdown)

store-requests privileged-interfaces
1

Description

name: downman

description: DownMan is a low-footprint, aria2-powered download manager for Linux (Tauri + React UI) — torrent/magnet support, one-click media capture (yt-dlp + ffmpeg for HLS/DASH), download profiles, collections, and companion browser extensions.

snapcraft.yaml: DownMan/snap/snapcraft.yaml at main · rai-himanshu07/DownMan · GitHub

upstream: https://github.com/rai-himanshu07/DownMan

upstream-relation: I am the upstream author/maintainer of DownMan.

Interfaces requested

1. browser-cookies (personal-files)

  • attributes: read: $HOME/.mozilla/firefox, $HOME/.config/google-chrome, $HOME/.config/chromium, $HOME/.config/BraveSoftware/Brave-Browser, $HOME/.config/microsoft-edge, $HOME/.config/vivaldi, $HOME/.config/opera
  • request-type: installation
  • reason: yt-dlp’s --cookies-from-browser needs read access to these browser profile directories to import cookies for authenticated downloads (e.g. members-only video). These are hidden (dotfile) paths not covered by the home interface. Read-only.

2. autostart-entry (personal-files)

  • attributes: read/write: $HOME/.config/autostart
  • request-type: installation
  • reason: Powers the “run at startup” toggle in Settings, which writes/removes a .desktop file in the user’s autostart directory. Read access lets the toggle reflect the current on-disk state.

3. mime-defaults (personal-files)

  • attributes: read/write: $HOME/.config/mimeapps.list
  • request-type: installation
  • reason: Powers the “Set as default download manager” button, which needs to read/update the user’s real mimeapps.list (the home interface excludes dotfiles, so the snap-isolated copy is never seen by other apps).

4. display-config (personal-files)

  • attributes: read: $HOME/.config/monitors.xml
  • request-type: installation
  • reason: Used only to read GNOME/mutter’s monitor layout so the main window can be centered on the user’s actual primary display under Wayland (which has no API to query “primary monitor”). Read-only.

5. shutdown

  • attributes: (none)
  • request-type: installation
  • reason: Optional “suspend/shut down when downloads finish” feature, calling org.freedesktop.login1.Manager over D-Bus.

Notes

None of these are requested for auto-connection - all are manual-connect (slots: none); users opt in via snap connect, and the project ships a snap_connect.sh helper for this. This request is only to unblock allow-installation, since snapd’s base declaration currently prevents the snap from being installed/distributed at all with these plugs declared.

2

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

3

Hey @himanshurai

  1. browser-cookies (personal-files)

This is highly privileged as it contains sensitive information (browser cookies), but I think manual-connection may be ok if the plug/s name makes it clear. We’ll need to agree on a name for it

  1. autostart-entry (personal-files)

Write access to $HOME/.config/autostart enables sandbox escape and it is never granted (not even manual). Could you please take a look at the solutions outlined in https://forum.snapcraft.io/t/manual-review-request-shadowsocks-electron/27830/2 and Auto-connect “personal-files” request, for 1st Money - #2 by alexmurray?

  1. mime-defaults (personal-files)

I think write access to $HOME/.config/mimeapps.list can also be abused to escape the confinement and should not be granted.

  1. display-config (personal-files)

I’m not entirely against this, but could you please investigate whether there is or not more standard and reliable way to achieve it? I’m not familiar with wayland but it is weird that reading the ~/ .config/monitors.xml file is the only/recommended way to achieve this.

  1. shutdown

I’m fine with this one

Thanks

1 Like
4

Hi @jslarraz,

Thank you for the detailed guidance. I have updated the implementation and packaging accordingly.

1. Browser cookies (personal-files)

I renamed the plug to read-browser-cookies so its sensitive purpose and read-only nature are explicit when users manually connect it.

The paths and permissions remain read-only. Would read-browser-cookies be an acceptable name?

2. Autostart

I removed the autostart-entry personal-files plug completely.

DownMan now uses Snap’s supported autostart mechanism:

apps:
  downman:
    autostart: downman.desktop

The application creates the desktop entry under:

$SNAP_USER_DATA/.config/autostart/downman.desktop

It no longer reads or writes the host’s ~/.config/autostart directory.

3. MIME defaults

I removed the mime-defaults personal-files plug completely.

The exported desktop entry still advertises support for:

  • x-scheme-handler/magnet
  • application/x-bittorrent
  • application/metalink4+xml

This allows DownMan to appear as an available handler. Under Snap confinement, the application now directs users to their desktop’s Open With or Default Applications settings instead of modifying ~/.config/mimeapps.list.

4. Display configuration

I investigated the Wayland behavior further.

The Wayland xdg-shell protocol does not expose a standard primary-output concept or an API for clients to position ordinary top-level windows at arbitrary screen coordinates. Window placement is ultimately controlled by the compositor.

DownMan’s Snap build now uses Tauri’s standard primary_monitor() API when a primary monitor is available. If it is unavailable, the application leaves placement to the compositor.

It no longer reads ~/.config/monitors.xml, and the display-config plug has been removed.

References:

5. Shutdown

The shutdown plug is retained unchanged. Thank you for confirming that this one is acceptable.

Updated source

The complete changes are available here:

The revised Snap now contains only these two super-privileged interfaces:

  • read-browser-cookies
  • shutdown

I have prepared and validated the replacement Snap package. I will upload the new revision after confirming that read-browser-cookies is an acceptable plug name.

Thanks.

5

@review-team any update?

6

Hey @himanshurai

read: $HOME/.mozilla/firefox, $HOME/.config/google-chrome, $HOME/.config/chromium, $HOME/.config/BraveSoftware/Brave-Browser, $HOME/.config/microsoft-edge, $HOME/.config/vivaldi, $HOME/.config/opera

We need to check if we can narrow these paths to the concrete cookies directories.

Besides that, I’m ok with this as far as:

  • it is read access
  • manual connection
  • the name makes it clear the sensitivity of the information exposed

Would read-browser-cookies be an acceptable name?

I would possibly prefer read-browser-secrets as some users may not be aware that cookies actually carry authentication information. Then, in the documentation where you instruct the user to connect the interface, you can explain that only cookies are used and add a link to the snap-declaration from the store, so that users can check what concrete paths are being exposed if they want.

what other @reviewers think?

7

Hello @himanshurai :slight_smile:

Given the discussion you had with @jslarraz:

  1. It is a +1 from my my side for granting the shutdown interface.

  2. Concerning the personal-files request, and specifically on the path narrowing: personal-files doesn’t support globs, which creates practical limits:

    • Firefox profiles are non-deterministic (<random>.default-release), so targeting cookies.sqlite directly isn’t feasible without listing every profile.
    • Chromium-based browsers use predictable sub-paths (Default/Cookies), but multiple or custom profiles still break fixed paths.

    Directory-level access is likely unavoidable for full browser support. @himanshurai — have you tested narrowing to top-level cookie paths for the default profile, and can DownMan gracefully skip browsers if a narrow path fails?

    If narrowing is impractical, directory read access is fine for this scope. We should just document exactly what is read and why in the plug’s description: field in snapcraft.yaml.

    After renaming the plug to something that clearly signals sensitivity like read-browser-secrets, and a short confirmation on whether narrower (file-level, not directory-level) paths were actually tested and found infeasible, or whether they can be tightened further, I am also ok with granting manual-connection to this plug.