pgAdmin Shared Servers Need Credential and Role Separation
pgAdmin is a database administration client that can run as a multi-user web service. That makes it a high-value control plane: a user may read saved connection metadata, open query tools, manage roles, or reach a server whose database password is stored by the application. The most important review question is not whether pgAdmin is online. It is which user can see which shared server and which credentials remain local to each user.
A count-only ZoomEye observation on 2026-11-15 used sub_type=all, page 1, and page size 1. app="pgAdmin" returned zero, title="pgAdmin" returned 48,093, and http.body="pgAdmin" returned 112,970. The zero is a field-specific result and does not establish absence. The title and body values include documentation and general references, so they are candidate-discovery signals rather than a count of server-mode deployments.
pgAdmin's server documentation says that sharing a server is restricted to users with the Administrator role. It also says the owner's password, SSH tunnel credentials, SSL certificate and key paths, and password file are never shared; each user must supply their own server password when needed. That separation is important. A shared server can share connection metadata and access policy without sharing every user's database secret.
Review roles and shared ownership
List administrators, shared servers, owners, and the user groups that can view them. Check for servers shared before a role restriction was introduced. The documentation notes that a server shared earlier may be owned by a non-administrator, so the shared flag alone is not proof that the current owner has administrator rights.
Use the OAUTH2_SERVER_GROUP_CLAIM setting when OAuth is enabled to restrict which shared servers a user can see from an identity-provider claim. Verify the claim mapping and what happens when the claim is missing or changed. A display name in the identity provider is not an authorization group.
Protect saved credentials
The master password protects saved server passwords, but its assurance depends on the storage mode and the user's login method. Review the configuration, test that an exported server list cannot reveal another user's password, and confirm that password changes re-encrypt the saved state. A shared storage passfile needs a separate review because it can make a password available to multiple processes.
Lockout settings also depend on the authentication source. pgAdmin's documentation says the internal account lockout applies only to internal accounts and warns that external authentication sources need their own brute-force protection. Put rate limiting and monitoring in front of LDAP, OAuth, and proxy-authentication paths.
Use the title query as a candidate list
title="pgAdmin"
The 48,093 title observations need validation before they become a server-mode inventory. A candidate may be a desktop landing page, a documentation mirror, or a login behind a proxy. Once confirmed, check the authentication mode, administrative role list, shared-server setting, and master-password policy.
Test separation
Create two non-admin users and share one server with only one of them. Verify that the second user cannot discover the server, its connection metadata, or a saved password. Test administrative sharing, OAuth group claims, and account disablement. A disabled user should lose access to the control plane and not continue through a live session.
pgAdmin can be useful for a team when the role model is explicit. The control that matters is the separation between database credentials, shared connection metadata, and administrative authority. A public observation should lead to that review, not to a conclusion based on a title string alone.
Top comments (0)