Privileged interfaces request: rustconn (personal-files, system-files)

store-requests privileged-interfaces
1
  • name: rustconn
  • description: GTK4/libadwaita connection manager for Linux — SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, and Zero Trust protocols with embedded Rust clients
  • snapcraft: RustConn/snap/snapcraft.yaml at main · totoshko88/RustConn · GitHub
  • upstream: GitHub - totoshko88/RustConn: Modern connection manager for Linux with GTK4/Wayland-native interface. · GitHub
  • upstream-relation: I am the upstream author and sole maintainer
  • interfaces:
    • aws-credentials (personal-files, write: $HOME/.aws):
      • request-type: installation
      • reasoning: AWS SSM Session Manager requires read access to AWS credentials and write access for SSO token cache (~/.aws/sso/cache/). Used for Zero Trust SSH connections through AWS Systems Manager.
    • gcloud-credentials (personal-files, read: $HOME/.config/gcloud):
      • request-type: installation
      • reasoning: GCP IAP tunnel connections require reading gcloud CLI credentials and project configuration. Read-only access.
    • azure-credentials (personal-files, read: $HOME/.azure):
      • request-type: installation
      • reasoning: Azure Bastion connections require reading Azure CLI authentication tokens. Read-only access.
    • oci-credentials (personal-files, read: $HOME/.oci):
      • request-type: installation
      • reasoning: OCI Bastion connections require reading Oracle Cloud CLI configuration and API keys. Read-only access.
    • kube-credentials (personal-files, read: $HOME/.kube):
      • request-type: installation
      • reasoning: Kubernetes pod exec connections require reading kubeconfig for cluster authentication. Read-only access.
    • host-usr-bin (system-files, read: /usr/bin/aws, /usr/bin/gcloud, /usr/bin/az, /usr/bin/oci, /usr/bin/cloudflared, /usr/bin/tsh, /usr/bin/tailscale, /usr/bin/boundary, /usr/bin/bw, /usr/bin/op, /usr/bin/passbolt, /usr/bin/keepassxc-proxy, /usr/bin/remote-viewer, /usr/bin/xfreerdp, /usr/bin/vncviewer, /usr/bin/kubectl, /usr/local/bin/kubectl):
      • request-type: installation
      • reasoning: RustConn optionally executes host-installed CLI tools for: (1) Zero Trust providers — aws, gcloud, az, oci, cloudflared, tsh, tailscale, boundary; (2) password managers — bw (Bitwarden), op (1Password), passbolt, keepassxc-proxy; (3) protocol fallback clients — xfreerdp, vncviewer, remote-viewer; (4) container orchestration — kubectl. All are optional — the snap works without them using embedded protocol clients. Read-only access to binaries only.
Dbus slot declaration request: rustconn (dbus)
2

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

3

Hello @totoshko88 :slightly_smiling_face:

Given the justification provided and the snap’s core functionality, the requests for personal-files interfaces are well-reasoned. However, due to the highly sensitive nature of the data stored in these directories, I do not believe they meet the criteria for auto-connection.

Instead, I suggest proceeding with manual connection for the following interfaces:

  • aws-credentials
  • gcloud-credentials
  • azure-credentials
  • oci-credentials
  • kube-credentials

so this is a +1 (#voteFor) for manual-connecting these interfaces .

Regarding the system-files request for host-usr-bin: I’ve reviewed your previous post regarding classic confinement, and I agree with the points raised by @jslarraz. Therefore, this is a -1 (#voteAgainst) on the system-files request. I strongly recommend staging (bundling) the necessary binaries within the snap itself.

4

Hey folks!

Thinking a bit more about this request, I think that File Chooser - XDG Desktop Portal documentation is possibly a better solution than the manually connected personal-files interface.

Thanks

6

Thank you @yomonokio and @jslarraz for the feedback!

Regarding system-files (host-usr-bin): I have removed this request entirely in v0.15.3. Following the feedback from @jslarraz in the classic confinement thread, I implemented an on-demand download mechanism (similar to what the Flatpak version already does): external CLI tools (aws, gcloud, tsh, bw, op, etc.) are now downloaded into the snap’s writable user data directory ($SNAP_USER_DATA/cli/) and executed from there - no host binaries are accessed. The updated snapcraft.yaml no longer contains the system-files plug at all.

Regarding personal-files and the XDG FileChooser portal suggestion (@jslarraz): Thank you for the pointer. I’ve thought about this carefully:

The personal-files plugs here are not for user-selected files (where FileChooser would be the right tool). They are for pre-existing machine-level credential stores that cloud CLIs write to automatically:

~/.aws - AWS CLI credentials and SSO token cache (written by aws sso login) ~/.config/gcloud - gcloud auth tokens (written by gcloud auth login) ~/.azure - Azure CLI tokens (written by az login) ~/.oci - OCI CLI config (written by oci setup config) ~/.kube - kubeconfig (written by kubectl config) These paths are fixed by the respective CLIs - the user cannot choose them. FileChooser is designed for user-initiated file selection dialogs, not for background credential access. The snap needs to read these directories silently when establishing a Zero Trust connection, without prompting the user each time.

I am happy to proceed with manual connection as suggested by @yomonokio. The snap already shows a sudo snap connect rustconn: hint in the UI when a credential directory exists on the host but the plug is not connected.

Updated snapcraft.yaml alredy in repo

8

Fair enough, I’m ok with manual-connection in that case. Whilst the personal-files interfaces do not follow the usual naming convention, I think the names used are better in this case (it is more clear that connecting the interface will grant the snap access to the credentials). The only remaining concern is that should not grant write access to the complete $HOME/.aws. Write access should be limited to ~/.aws/sso/cache/

aws-credentials:
  interface: personal-files
  read: 
    - $HOME/.aws
  write:
    - $HOME/.aws/sso/cache

+2 for, 0 against granting rustconn access to the requested directories via personal-files interface manual connection. This is now live.

New revisions of your snap should pass automatic connection once the requested modification for the aws-credentials plugs has been done

9

Thanks @jslarraz for the review and approval!

I’ve updated the aws-credentials plug as requested - write access is now limited to ~/.aws/sso/cache/ only, while read covers the full ~/.aws directory:

aws-credentials:
  interface: personal-files
  read:
    - $HOME/.aws
  write:
    - $HOME/.aws/sso/cache

A new revision (v0.15.7) has been pushed to the store. Let me know if anything else is needed.

10

Newest revisions are already green ^^

1 Like