Skip to main content

phpMyAdmin and pgAdmin

Next to each database there is a button named after its tool: phpMyAdmin for MySQL and MariaDB servers, pgAdmin for PostgreSQL (phpMyAdmin does not support PostgreSQL). pgAdmin is the larger of the two: its image is about 600 MB and it takes around ten seconds to start, so the first opening downloads it and every later one waits a little longer than phpMyAdmin does. It opens the database in a new tab, already logged in, and nothing needs to be installed or linked.

  • What happens when you press it. The new tab asks for your password if it was not confirmed recently, then shows its progress: getting the tool ready (the first time it downloads the official image, 100 MB for phpMyAdmin and about 600 MB for pgAdmin; after that a moment), starting it next to your database, waiting for it to answer, and opening it in the same tab. If something fails it says why and offers Try again.
  • What you get. The tool is logged in as that database's own user, so you see this database and nothing else on the server (not the other databases, and not the administrator account). You can browse and edit data, run SQL (pgAdmin's Query Tool), and import or export dumps up to 128 MB. Everything you do happens to the real database.
  • It closes by itself. The tool is a small container started for you alone. After 15 minutes without activity (and after four hours at most, however busy) it is stopped and deleted; nothing stays installed or running. Opening the database again starts a fresh one. A database has one open tool at a time: opening it again replaces the first.
  • Permission. It needs databases.tools, a separate permission that the built-in admin role has and custom roles do not until you grant it. Treat it like the database's password: whoever holds it can read and change the data. It asks for your password, and every start and opening is recorded in the audit log.
  • How pgAdmin is set up. It runs in single-user mode, with its mail server, PSQL shell and update check switched off. It starts with no server in it; when you open the database, the agent adds this one database as a server and connects it with the database user's password, which pgAdmin keeps only in memory for your browser session and never saves. The password is in no file or environment variable of the container, and anything else that reaches the container's port sees an empty pgAdmin with no connection. Its PSQL shell is off because it needs a WebSocket, which the proxy does not pass.
  • Not for the whole server. There is no administrator login to the database server here, only each database's own user. To work as the administrator, use the command line on the server.

The port, and why it is a different one​

The tools are served on port 2053 (set COMMYPANEL_TOOLS_PORT to change it), on the same address as the panel: https://panel.example.com:2053 once the panel has a domain, with the same certificate, or https://<server address>:2053 with the panel's self-signed one (your browser warns once more for that port). Open that port in your firewall, next to 80, 443 and 8443; the installer prints the reminder.

The port is not a detail. A browser treats the same address on another port as another website. phpMyAdmin and pgAdmin are third-party web applications that show whatever is in your database, and that can include text a stranger typed into a form on your site. If such text ever fooled a tool into running a script, that script would be in the tool's website, not the panel's, and the browser would not let it read the panel's pages or send it requests as you. The agent's proxy also never passes the panel's login cookie on to a tool, never lets a tool set a cookie outside its own session, drops headers that reach beyond the tool's own page (such as Strict-Transport-Security and Clear-Site-Data), and does not follow a redirect to anywhere else. The tool is also never logged in from its own container: neither tool holds the database password, the agent logs in for the browser it lets in, so a process on the server that finds the tool's local port meets a login form.

What a port does not separate: cookies. Browsers key cookies by host name, not by port, so the panel's cookies are sent to the tools port too (the proxy removes them before they reach a tool, and the login cookie is HttpOnly, so a script cannot read it). A script that ran in a tool could still fill the browser's cookie storage for that host, which would make the browser's requests to the panel fail until its cookies are cleared (a nuisance, not a way in), and could read the panel's one cookie that is not HttpOnly, which is of no use from another origin. A tool would have to be fooled first, which is the part we rely on phpMyAdmin and pgAdmin for. A separate host name would remove even this; it needs a DNS record and a certificate for it, and is planned together with wildcard certificates.

If you put the panel behind Cloudflare's proxy (the orange cloud), keep a port Cloudflare passes: 443, 2053, 2083, 2087, 2096 or 8443. 2053 is one of them. Cloudflare's free plan limits uploads to 100 MB and cuts requests after about 100 seconds, so a very large import through the tool can fail there; switch the record to DNS only for it, or load the dump from the command line.