La consola es un privilegio: por qué pide su propio permiso

Una consola parece una pantalla. La abres, aparece una ventana, dentro corre texto. Da la sensación de "solo estoy mirando".

Sin embargo una consola es un intérprete de órdenes. Y el intérprete del servidor es el derecho más alto que existe en esa máquina.

Dos poderes distintos

Cambiar ajustes. Puedes hacer lo que la interfaz permite. Los límites están claros, porque los traza la interfaz.

Abrir un intérprete. Puedes hacer cualquier cosa. También lo que la interfaz rechazaría y lo que la interfaz nunca ha oído nombrar.

Estos dos poderes no se contienen el uno al otro. Tener uno no exige el otro y, más importante: conceder uno no debería significar conceder el otro.

La distinción es real y se ve en los roles integrados

Proxmox ata la consola a su propio permiso, no al permiso general de "puede cambiar". Que esto es real se ve en los roles integrados: el rol de administrador del sistema lleva los derechos de auditoría, consola y registro y no contiene el derecho de cambio.

Así que es una configuración legítima dar a alguien el derecho de abrir una consola sin el derecho de cambiar ajustes. Y al revés también.

La situación común que hace esto importante

Proxmox permite crear roles personalizados, y un rol así es muy habitual: un operador que puede cambiar los ajustes de red pero no debe llegar al intérprete del servidor.

Es una petición razonable. Editar la configuración de red y ejecutar cualquier orden en el servidor no son lo mismo.

Pero si un producto razona "si puede cambiar, también puede abrir la consola", le entrega a ese operador un intérprete de root sin darse cuenta. Consigue por el panel lo que no conseguiría en Proxmox.

El principio general que se deriva

Un modelo de permisos debe copiar la definición propia de la plataforma, no parafrasearla.

Una puerta que dice "más o menos lo mismo" funciona bien en instalaciones corrientes y nadie se da cuenta. El hueco se abre el día en que se crea un rol poco habitual. Y ese día nadie recuerda una aproximación escrita años antes.

El mismo listón vale para el acceso a archivos

Un detalle más, porque se pasa por alto a menudo: el acceso al sistema de archivos del servidor equivale a un intérprete aunque sea solo de lectura.

El motivo es simple: en ese sistema de archivos están los archivos de contraseñas, las claves y los secretos del clúster. Alguien con un derecho de solo lectura que puede leer archivos ya puede enterarse de todo.

Así que el acceso a archivos no se puede conceder con un derecho de "mirar"; exige el mismo listón que un intérprete.

Qué hace Atlas

En Atlas la consola, el intérprete remoto y el acceso a archivos están atados solo al permiso de consola. El derecho de cambio por sí solo no abre estas superficies.

No siempre fue así, y el artículo tiene que acabar con honestidad: antes estas superficies aceptaban también el derecho de cambio. El comentario del código decía lo correcto, decía "el equivalente es el permiso de consola", pero el código hacía otra cosa.

Se encontró midiendo contra la definición propia de Proxmox, y se corrigió. El resultado de la medición fue claro: Proxmox ata el intérprete solo al permiso de consola y no acepta el derecho de cambio.

También hay que decir el peso real tal cual: no era explotable con roles integrados, porque el único rol integrado que contiene el derecho de cambio tiene también el permiso de consola. El riesgo estaba en los roles personalizados, es decir, en el ejemplo del operador de red descrito arriba.

La lección que se deriva vale también para el propio producto: que un comentario tenga razón no significa que el código la tenga. Hay que medir los dos por separado.