Request personal-files, dbus for cloudsql-proxy-gui

store-requests privileged-interfaces
1

Hi, I would like to kindly ask you to review the following

  • name: cloudsql-proxy-gui

  • description: CloudSQL Proxy GUI is a desktop application that provides a graphical interface for managing Google Cloud SQL proxy connections (using official cloudsql proxy binary). It simplifies the process of connecting to Cloud SQL instances through a user-friendly Tauri-based interface, allowing developers and database administrators to manage multiple proxy connections, authenticate with Google Cloud, and monitor connection status. It uses gcloud cli created ADC credentials to:

    • call google api to retrieve GCP projects and SQL database instances
    • passes the adc file to the cloudsql proxy binary so that it can use it to authenticate the sql connection

  • snapcraft: PRIVATE

  • upstream: PRIVATE

  • upstream-relation: I am the developer of the gui app.

  • interfaces:

    • personal-files:
      • request-type: installation & auto-connection
      • reasoning: The application uses adc file present in the .config/gcloud folder to authenticate against google API and to run the CloudSQL Proxy binary from google. The ability to run CloudSQL proxy binary is a core feature and the adc file is required for it. As it is a hidden folder, I must use personal files and not other non-priviledged interfaces. Files in this folder are created by the official gcloud cli which handles the actual authentication to google. The plug is limited to read only. We dont need write.
    • dbus:
      • request-type: installation & auto-connection
      • reasoning: The application uses tauri-plugin-single-instance to prevent multiple instances from running simultaneously via D-Bus IPC with service name com.cloudsql-proxy-gui.app (I guess I need approval for this name?). This is important for a proxy management tool to avoid port conflicts, resource contention, and connection state confusion when managing Cloud SQL proxy processes. Single-instance enforcement ensures proper proxy port management and prevents multiple instances from interfering with each other.
2

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

3

The dbus request has been granted.

Do you have any links to documentation that describe this access of .config/gcloud? (#askForInfo)

1 Like
4

Hi cav, not sure if this is what you are asking for so please correct me if Im wrong but .config/gcloud is a well-known location on linux (docs) in google ecosystem which is used by gcloud cli itself to store eg. oauth tokens + this location is checked by cloudsql proxy to get the user identity (docs)

By linking it to snap using the plug, we dont need to ship the whole gcloud cli binary inside the package (+ dealing with interactive/noninteractive oauth flows) or rolling our own oauth client. So users are guided to have gcloud cli installed in any way they like and generating ADC file using their company google account. Not using our own oauth client is mostly “future-proofing” the setup so that once we open source the app, there is no dependency of other users on our own GCP as this app doesnt even have any backend.

5

Considering that this personal-files interface will expose google cloud credentials (which is considered sensitive information) to the snap, I think strong snap/publisher vetting would be required.

I could not even find any single reference to cloudsql-proxy-gui over internet. Thus, I give a -1 to this request (#voteAgainst)

6

Hi jslarraz, I agree that there are sensitive values being access - it is required for the google proxy binary. I am aware of two options that can allow us to make this app - A, classic snap B, restricted snap with this interface… if you are aware of a third option which would fit more into the snapcraft way of doing things, I would love to learn.

Would moving to manually (therefore users can make the decision themselves if they trust the app once it goes public, through github source code) connected interface and scoping the interface read to a file “application_default_credentials.json” which contains this:

{
  "account": "",
  "client_id": "764086051850-6qr4p6gpi6hn506pt8ejuq83di341hur.apps.googleusercontent.com", //public value
  "client_secret": "d-FL95Q19q7MQmFpd7hHD0Ty", //public value
  "quota_project_id": "rhl-infrastructure-base",
  "refresh_token": "value",
  "type": "authorized_user",
  "universe_domain": "googleapis.com"
}

be acceptable to get this approved?

7

Given the user would have to manually connect and if there was documentation (snap description) indicating what file is needed, I think +1 (#voteFor) manual connection

8

what do other @reviewers think? (#askForInfo)

9

I agree, giving read access to .config/gcloud would be dangerous. But given that it is a manual connection and mentioning the use case in the snap description should be fine.

I also recommend as @jslarraz said, to have a strong publisher vetting before granting this.

+1 from my end (#voteFor) for manual connection

10

2 votes for and 0 votes against for manual connection of system-files (read).

@rhl-pmachacek - As this upstream is private, you will need to follow the verified publisher process outlined here:

Once this is complete, we can make the changes live. Thanks!