The console is a privilege: why it asks for its own permission

A console looks like a screen. You open it, a window appears, text scrolls inside it. It feels like "I am only looking".

But a console is a shell. And a shell on the server is the highest privilege that exists on that machine.

Two separate powers

Changing settings. You can do the things the interface allows. The limits are clear, because the interface draws them.

Opening a shell. You can do anything. Including things the interface would refuse, and things the interface has never heard of.

These two powers do not contain each other. Having one does not require the other, and more importantly: granting one should not mean granting the other.

The distinction is real, and it shows in the built-in roles

Proxmox binds the console to its own separate permission, not to the general "can change" permission. You can see this is real in the built-in roles: the system administrator role carries the audit, console and log permissions and contains no change permission.

So it is a legitimate setup to give someone the right to open a console without the right to change settings. And the other way round too.

The common situation that makes this matter

Proxmox allows custom roles to be created, and a role like this is very common: an operator who can change network settings but should not reach the server's shell.

That is a reasonable request. Editing network configuration and running any command you like on the server are not the same thing.

But if a product reasons "if they can change, they can also open the console", it hands that operator a root shell without noticing. They get through the panel what they could not get in Proxmox.

The general principle that follows

A permission model must copy the platform's own definition, not paraphrase it.

A gate that says "roughly the same thing" works correctly on ordinary setups and nobody notices. The gap opens on the day an unusual role is created. And when that day comes, nobody remembers an approximation written years earlier.

The same bar applies to file access

One more detail, because it is often missed: access to the server's filesystem is equivalent to a shell even when it is read only.

The reason is simple: password files, keys and cluster secrets live on that filesystem. Someone with a read-only permission who can read files can already learn everything.

So file access cannot be granted with a "looking" permission; it demands the same bar as a shell.

What Atlas does

In Atlas, the console, the remote shell and file access are bound to the console permission alone. The change permission on its own does not open these surfaces.

It was not always this way, and the article has to end honestly: these surfaces used to accept the change permission too. The comment in the code said the right thing, it said "the equivalent is the console permission", but the code did something else.

This was found by measuring against Proxmox's own definition, and it was corrected. The measurement was clear: Proxmox binds the shell to the console permission only and does not accept the change permission.

The real weight should also be stated as it is: it was not exploitable with built-in roles, because the only built-in role containing the change permission also has the console permission. The risk was in custom roles, that is, in the network operator example described above.

The lesson that follows applies to the product itself: a comment being right does not mean the code is right. The two have to be measured separately.