phpMyAdmin and pgAdmin by role
Server > Databases (/server/databases) has the way into phpMyAdmin and
pgAdmin. Who may use them, and as whom, depends on the role.
| Role | phpMyAdmin | pgAdmin |
|---|---|---|
| Super Admin | Signed in with the panel's own database login (the Open phpMyAdmin (administrator) button), or as any account's own login from the account's page | Under its own pgAdmin identity |
| Delegated administrator | Only per account, signed in as that account's own database login, once the Super Admin has granted it | Under an identity of its own with no saved server, once the Super Admin has granted it |
| Reseller | Only per account, for its own accounts, once the Super Admin has granted it | Not available |
The panel's own database login is the Super Admin's alone. Before 4.1.2 a delegated administrator could open phpMyAdmin with it; the route now refuses every role but the Super Admin.
phpMyAdmin as an account's own login
On an account's page (Users > the account) a phpMyAdmin (this account)
button opens phpMyAdmin signed in with that account's own database login: the
login in the account's own ~/my.cnf, the same one the customer panel uses
for its own phpMyAdmin. The server derives it from the account in the address:
- nothing about the database user or host is taken from the request, so a role cannot choose another login, root's, or another account's;
- a login that does not carry the account's own name, or that a longer account name claims, is not used;
- a reseller can only do this for an account it owns;
- an account with no database login of its own on file gets a message instead.
The button is drawn only to a role that may use it, and only while phpMyAdmin is served on the machine.
pgAdmin
A delegated administrator that was granted pgAdmin opens it under an identity
of its own (<name>@pgadmin-user.hitechcloud.invalid), so its saved servers
and the Super Admin's never meet. pgAdmin holds no database credentials:
what a person can connect to from inside it is what PostgreSQL grants the
login they type. A reseller has no page that leads to pgAdmin and cannot be
granted it.
Granting a role
The Super Admin sets the grants in Database tools for other roles at the
top of the Databases page: phpMyAdmin for delegated administrators and for
resellers, pgAdmin for delegated administrators. Every role is off until the
Super Admin grants it. The grants are kept in admin.ini, section
[DATABASE_TOOLS] (phpmyadmin_roles, pgadmin_roles).
The server's Databases page
The rest of the page is the server's own: every database and database login on
the server and the account it belongs to, the connections open right now with a
button that ends one, the resource limits of the database services, and the
SQL Server Access tab. Since 4.1.4 this is the Super Admin's, and a delegated
administrator's only once granted: tick This page for Delegated
administrators under Database tools for other roles (admin.ini,
[DATABASE_TOOLS] databases_page_roles). It is off until granted, so a
delegated administrator that had the page before 4.1.4 no longer sees it after
the update until the Super Admin ticks the box.
Without the grant a delegated administrator still opens the page for the tools it was given (pgAdmin), sees a note in place of the server's data, and ending a connection, changing the limits or opening SQL Server Access is refused before anything runs. A reseller never reaches the page.
What is recorded
Every sign-in is a POST that the audit log records with the person, their role, the account and whether it was refused (Compliance > Audit log). A sign-in to an account's phpMyAdmin is also written to that account's own activity log with the person and their role; opening pgAdmin is written to the person's own.