---
title: "How to Set Database User Privileges in ISPConfig"
description: "Choose between the read-write and read-only database user roles in ISPConfig, see what each common MySQL privilege allows, and apply least privilege safely."
url: "https://docs.noiz.ie/ispconfig/how-to-set-database-user-privileges-in-ispconfig/"
section: "ISPConfig"
categories:
  - "Control Panels > ISPConfig > Databases"
last_reviewed: "27 July 2026, against the ISPConfig release Noiz runs"
---

# 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 the ISPConfig release Noiz runs. 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](https://docs.ispconfig.org/): 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)](https://www.howtoforge.com/ispconfig-website/): a current walkthrough of the database and database-user forms, maintained by the ISPConfig developers' documentation site.
- [Privileges Provided by MySQL](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html): the authoritative reference for exactly what each privilege (SELECT, INSERT, CREATE, GRANT OPTION, SUPER, FILE and the rest) permits.
- [MariaDB GRANT statement](https://mariadb.com/kb/en/grant/): 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](/ispconfig/how-to-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](/ispconfig/how-to-create-a-database-and-database-user-in-ispconfig/) first; that guide also shows how to open the database in phpMyAdmin.

## 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.

![ISPConfig Add new Database form showing the Database user drop-down and the separate Read-only database user drop-down](/images/kb/252_ispconfig-database-form-user-dropdowns.png)

## 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. You cannot trim a user's privileges further yourself: changing another account's grants, or your own, needs the **GRANT OPTION** privilege, and as described above ISPConfig withholds it from every hosting database user. phpMyAdmin therefore cannot edit privileges when you log in with your own database user; its user-account and privilege screens are only usable by a server administrator. The MySQL [REVOKE](https://dev.mysql.com/doc/refman/8.4/en/revoke.html) and MariaDB [REVOKE](https://mariadb.com/kb/en/revoke/) references set out this requirement.

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, open a support ticket and Noiz can apply it with administrator access. Two cautions apply to any such change:

- **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 DDL is stripped from the user, updates can fail with permission errors until it is restored.
- **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. Re-check a customised user 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 its privileges were trimmed on request. Re-link it as the main **Database user** on the Database form, or ask Noiz support to 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 changes need administrator access, so ask Noiz support.
- **Manual privilege changes disappeared**: re-saving the database in ISPConfig can reapply the role's standard grants. Ask Noiz support to reapply the customisation, 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.

---
Source: https://docs.noiz.ie/ispconfig/how-to-set-database-user-privileges-in-ispconfig/