How to Set Database User Privileges in ISPConfig

This guide explains what a database user is allowed to do in ISPConfig, how to control it, and how to apply the security principle of least privilege so that each application on your Noiz hosting account can only do what it genuinely needs. "Privileges" are the same thing as database permissions or grants: the specific actions, such as reading rows or creating tables, that a MySQL or MariaDB user is authorised to perform. This is the companion to creating the database itself; if you have not yet made a database and a database user, do that first, then return here to understand and tighten what that user can do.

Last reviewed: 27 July 2026, against ISPConfig 3.3.1p1 (latest stable). This guide is written for Noiz hosting and is kept current against ISPConfig. It complements, and does not replace, the official ISPConfig and MySQL/MariaDB documentation linked below. ISPConfig and the underlying database server evolve between releases, so if a privilege list on your system differs slightly from the examples here, treat the official references as authoritative for the exact wording.

Official Documentation Reference

• ISPConfig 3 Documentation: the official online documentation for the current ISPConfig interface, including the Sites module and its Databases and Database Users forms.
• How to Add a Website, MySQL Database and Users in ISPConfig (HowtoForge): a current walkthrough of the database and database-user forms, maintained by the ISPConfig developers' documentation site.
• Privileges Provided by MySQL: the authoritative reference for exactly what each privilege (SELECT, INSERT, CREATE, GRANT OPTION, SUPER, FILE and the rest) permits.
• MariaDB GRANT statement: the equivalent reference for MariaDB, the database engine used on much of Noiz's Linux hosting; the privilege names match MySQL.

Prerequisites

• You can log in to the ISPConfig control panel.
• A database and at least one database user already exist on your account. If not, follow How to Create a Database and Database User in ISPConfig first; that guide also shows how to open the database in phpMyAdmin, which you will use later on this page to fine-tune privileges.

How ISPConfig Handles Database Privileges

This is the single most important thing to understand, because it differs from what you might expect if you have used raw MySQL commands. ISPConfig does not give you a grid of privilege checkboxes on the Database User form. Instead it offers a deliberately simple, two-role model on the Database form, and it sets the underlying grants for you:

• Database user (the main, read-write role): the user you select here is granted the full working set of privileges on that one database, by way of a single GRANT ALL PRIVILEGES scoped to that database alone. In practical terms that means it can read, write, and change the structure of the database: everything a normal web application needs to install and run.
• Read-only database user (optional second role): a user attached here is granted exactly one privilege, SELECT. It can browse and export data but cannot insert, update, delete, or alter anything.

Crucially, whichever role you choose, ISPConfig scopes the grant to that specific database and never hands out server-wide administrative privileges. A hosting database user on Noiz can only ever touch the database (or databases) it is linked to. It is never given the ability to manage the database server, other clients' data, or the underlying operating system. That platform-level boundary does a large part of the least-privilege job for you before you make any choices at all.

There is a third state that you do not choose, and it catches people out. If a database exceeds its Database quota, ISPConfig automatically downgrades the main user's grant: the user keeps SELECT, DELETE, ALTER and DROP, but loses INSERT and UPDATE. The intention is to let you clear space rather than lock you out of the data entirely. The full grant is restored automatically once usage falls back below the quota. A site that suddenly cannot write, with no privilege change on your part, is very often an over-quota database rather than a broken user.

The Principle of Least Privilege

Least privilege means giving each user exactly the permissions it needs to do its job, and nothing more. If a database user is ever compromised, for example through a vulnerability in a plugin or a leaked configuration file, an attacker inherits precisely that user's privileges. A tightly scoped user limits the blast radius to a single database; an over-privileged one can become a foothold into much more.

The reassuring news on Noiz ISPConfig hosting is that the most dangerous privileges are never granted to a hosting database user in the first place. An application user almost never needs any of these, and ISPConfig does not give them out:

• GRANT OPTION: lets a user hand its own privileges to other users. On shared hosting this would let one account escalate its own access, so it is withheld.
• SUPER (and its modern replacements): server-administration power such as killing other sessions or changing global server settings. This is a server-management privilege, not an application one.
• FILE: the ability to read and write files on the server's filesystem through the database (via LOAD DATA INFILE and SELECT ... INTO OUTFILE). This is a classic route for reading files that do not belong to you, and it is never appropriate for a website's database login.
• PROCESS, RELOAD, SHUTDOWN, CREATE USER: other server-wide administrative privileges that a single website has no reason to hold.

Because ISPConfig withholds all of these automatically, the one least-privilege decision that is actually in your hands is simple: does this particular user need to write, or only to read? Give an application its normal read-write user, but if you are wiring up something that should only ever look at data (a reporting dashboard, an analytics feed, a public read-only mirror), attach it as the read-only user instead of the main one.

What the Common Privileges Actually Mean

Even though ISPConfig sets the grants for you, it helps to know what the read-write user is being given, so you can reason about what an application needs. Privileges fall into a few natural groups.

Data privileges (day-to-day application use)

These are the four your application uses on every page load. Collectively they are known as DML, or data manipulation:

• SELECT: read rows from tables. Needed by absolutely everything, including read-only users.
• INSERT: add new rows, for example when a visitor submits a comment or an order.
• UPDATE: change existing rows, for example editing a post or updating a stock count.
• DELETE: remove rows.

A content-managed site that has already been installed spends almost all of its time using only these four. In principle, a fully installed and settled application could run on SELECT, INSERT, UPDATE and DELETE alone.

Structure privileges (installers and updates)

These change the shape of the database rather than its contents, and are known as DDL, or data definition:

• CREATE and DROP: make and remove tables.
• ALTER: change a table's columns or indexes, for example adding a new field.
• INDEX: add or remove indexes to speed up queries.

An application needs these at two specific moments: during initial installation, when it builds its tables, and during upgrades, when a new version of the software or a plugin adds or reshapes tables. WordPress core updates, Joomla extension installs, and database migration scripts all rely on DDL privileges. This is why installers ask for a user with full access rather than a read-only one.

Utility privileges

• LOCK TABLES and CREATE TEMPORARY TABLES: used by some applications for consistency during multi-step operations, and by backup tools such as mysqldump to produce a consistent export.
• CREATE VIEW / SHOW VIEW, CREATE ROUTINE / ALTER ROUTINE / EXECUTE, TRIGGER, EVENT: used by more advanced applications that define views, stored procedures, triggers, or scheduled events. Most simple sites never use them, but the read-write user holds them so that software which does use them works without a support ticket.

The ISPConfig read-write user is granted the data, structure, and utility privileges above, all confined to its own database. It is not granted GRANT OPTION or any server-wide privilege. The read-only user is granted exactly one privilege, SELECT. That is enough to browse and export data but not to change it. Note that it does not include LOCK TABLES, so a mysqldump run as the read-only user needs --single-transaction or --skip-lock-tables to complete.

Choosing the Right Role in ISPConfig

Applying least privilege in the ISPConfig interface comes down to picking the correct role when you link a user to a database:

1. Log in to the ISPConfig control panel and open the Sites module.
2. Under Databases in the left menu, click Databases and open the database you want to configure, or click Add new Database to create one.
3. In the Database user drop-down, select the user that your application will use to read and write data. This is the read-write role and suits the vast majority of websites.
4. Use the Read-only database user drop-down only when you have a second user that must never modify data. Leave it set to None otherwise. Do not put the same user in both fields: ISPConfig applies the read-only grant after the read-write one, so a user named in both ends up holding SELECT alone and the application loses its write access.
5. Click Save and wait for the small red change indicator near the top of the panel to clear; ISPConfig applies the grants on the server in the background, usually within a minute.

A single database user can be linked to more than one database if you reuse it across the Database form for several sites. Each link is scoped independently, so the same login can be read-write on one database and never touch another.

Fine-Tuning Privileges Beyond the Two Roles

ISPConfig's two-role model is the right tool for almost every situation, and Noiz recommends staying with it. If you have a specific hardening requirement that the two roles cannot express, for example trimming a settled application's user down to data privileges only after installation, the panel-agnostic tool for that is phpMyAdmin, which you reach from the database row in ISPConfig as described in How to Create a Database and Database User in ISPConfig.

Inside phpMyAdmin, with the database selected, the Privileges tab lists the users attached to that database and lets you edit the exact privileges a user holds on it. From there you could, for instance, remove the structure (DDL) privileges from an application user once it is fully installed, then re-grant them temporarily whenever you run an upgrade.

Two important cautions before you do this:

• Many applications break if you remove structure privileges. Auto-updaters in WordPress, Joomla, and similar software expect to be able to alter tables at any time. If you strip DDL from the user, updates can fail with permission errors until you restore it. Only trim privileges on an application you understand well, and document what you changed.
• ISPConfig may reassert its own grants. Because ISPConfig manages the read-write and read-only roles, editing the same database later in the panel (for example re-saving the Database form) can restore the full role grants. Treat manual privilege trimming as an advanced, self-managed customisation, and re-check it after any change made through ISPConfig.

How ISPConfig Keeps a User Scoped to One Database

Three mechanisms work together so that a hosting database user stays inside its own lane:

• Per-database grants. When you link a user to a database, ISPConfig grants privileges on that one named database, not on the whole server. A user linked to c1shop has no access to c1blog unless you separately link it there too.
• Account name prefixes. ISPConfig automatically prefixes database and user names with a per-account code, for example c1, so names cannot collide with, or be confused for, another client's. Your real database and username always include this prefix.
• Connection host restriction. On a standard Noiz hosting account the database is reached over localhost, meaning the user only works for software running on the same server as the database. External connections are refused unless you deliberately enable Remote Access on the Database form. If you do enable it, fill in Remote Access IPs as well, which takes a comma-separated list of addresses. Read that field's label carefully: leaving it blank does not mean "no remote hosts", it means any host may connect. Access over localhost remains available either way. Leaving remote access off entirely is both the more secure and the least-privilege default.

Troubleshooting

• An install or upgrade fails with a permissions or "command denied" error: the user probably lacks the structure (DDL) privileges the installer needs, most often because it was attached as the read-only user or was manually trimmed in phpMyAdmin. Re-link it as the main Database user on the Database form, or restore its structure privileges, then run the install again.
• Writes fail but reads still work: check the database against its Database quota on the Database form. An over-quota database has its main user's INSERT and UPDATE privileges withdrawn automatically, which leaves reads and deletions working and makes the fault look like a corrupted user. Free up space or ask for a larger quota, and the full grant returns on its own.
• A read-only integration can still write data: check the Database form. The user must be in the Read-only database user field, not the main Database user field. A user placed in the main field always has full read-write access regardless of your intent.
• You cannot find privilege checkboxes in ISPConfig: this is expected. ISPConfig intentionally exposes only the read-write and read-only roles. Per-privilege editing is done in phpMyAdmin, not in the ISPConfig panel.
• Manual privilege changes disappeared: re-saving the database in ISPConfig can reapply the role's standard grants. Reapply your customisation in phpMyAdmin, and avoid re-editing that database through the panel unless necessary.
• An external tool is refused: the user is scoped to localhost by default. Remote connections require Remote Access to be enabled with the connecting IP address listed. For occasional administration, using phpMyAdmin from within the panel avoids opening remote access at all.

If you are unsure which privileges an application needs, or you want help hardening a database user without breaking updates, open a support ticket with the Noiz support team and include the database name, the database username, and the website it belongs to. Never include the database password in a ticket. On managed plans, Noiz can review and apply a least-privilege configuration for you.