Cómo configurar admins y permisos ACL en MTA:SA
Guía técnica para configurar admins y permisos ACL en MTA:SA — editar acl.xml, crear grupos, asignar cuentas y blindar el servidor contra escalada de privilegios.
El sistema de permisos de MTA:SA está controlado por un archivo XML llamado acl.xml que define grupos, cuentas y derechos granulares por resource. Configurar admins correctamente es lo que separa un servidor que acepta moderación organizada de uno que se vuelve tierra de nadie — o peor, queda vulnerable a escalada de privilegios porque alguien recibió general.ModifyOtherObjects sin darse cuenta de lo que eso permite.
Este tutorial cubre el ciclo completo: crear cuentas en la base interna de MTA, definir grupos de admin y moderador con alcances distintos, mapear permisos en el acl.xml sin exponer el resource admin a usuarios comunes, y validar todo in-game antes de liberar al equipo. Tiempo estimado: 20-30 minutos.
La persona objetivo es un owner de servidor MTA:SA que ya tiene el mtaserver corriendo y necesita configurar al equipo de moderación por primera vez. Los comandos asumen servidor en Linux (Ubuntu 24.04 LTS), pero el contenido del acl.xml es idéntico en Windows.
Requisitos previos
Servidor MTA:SA ya instalado y corriendo, acceso al directorio de configuración del servidor (mods/deathmatch/), shell de consola activa (terminal del mtaserver o cliente in-game con login admin) y el resource admin instalado e iniciado.
Verifica que tengas acceso a todo esto antes de continuar:
mods/deathmatch/acl.xml mods/deathmatch/internal.db admin stdin del mtaserver El acl.xml se edita cuando el servidor está detenido. Para cambios en runtime, usa los comandos aclgroup, aclrights y aclrequest en la consola — estos persisten correctamente sin disputa con el autosave de MTA.
Entender la estructura del acl.xml
El acl.xml tiene tres bloques principales: <group> (asocia objetos a ACLs), <acl> (define permisos granulares) y los objetos referenciados (usuarios, resources). La relación es: un grupo contiene objetos y ACLs; los objetos son quienes ganan los permisos; los ACLs son los paquetes de permiso.
Un servidor MTA fresh tiene este layout por defecto en el acl.xml:
<acl>
<group name="Admin">
<object name="user.admin"/>
<object name="resource.admin"/>
<acl name="Admin"/>
<acl name="Moderator"/>
<acl name="RPC"/>
</group>
<group name="Moderator">
<acl name="Moderator"/>
<acl name="RPC"/>
</group>
<group name="Everyone">
<object name="user.*"/>
<object name="resource.*"/>
<acl name="Default"/>
</group>
</acl>Nota que Everyone incluye user.* y resource.* con el ACL Default — ese es el piso de permiso para cualquier login. El grupo Admin agrega ACLs específicos por encima, heredando lo que Everyone ya da.
Crear la cuenta de admin
Conéctate a la consola del servidor. Si usas systemd, accede vía socket:
sudo systemctl status mtasaPara enviar comandos, necesitas la consola adjunta. En servidores corriendo vía screen o tmux, reasocia a la sesión:
screen -r mtaserverSi usas systemd con stdin redirigido, el método varía por setup — el más común es ingresar al servidor in-game como cualquier player, autenticarse una vez con la cuenta por defecto admin y usar los comandos vía chat con /.
Crea la cuenta nueva con contraseña fuerte (mínimo 12 caracteres, mezcla de letras, números y símbolos):
addaccount nombredeladmin ContrasenaFuerteAqui123!El retorno Account 'nombredeladmin' created successfully confirma que la credencial fue guardada en internal.db. La contraseña se almacena con hash SHA-256 — no se puede recuperar, solo resetear.
La cuenta admin con contraseña admin que viene por defecto es el vector de invasión más explotado en servidores MTA:SA nuevos. Cambia la contraseña de inmediato o elimina la cuenta por defecto después de crear la tuya: delaccount admin.
Agrega la cuenta al grupo Admin vía consola:
aclgroup add Admin user.nombredeladminEl comando edita el acl.xml en runtime sin necesidad de reiniciar. Confirma con:
aclgroup listDebes ver nombredeladmin listada dentro del grupo Admin.
Crear grupos personalizados con permisos granulares
Por defecto solo trae Admin y Moderator. Para equipos más grandes querrás separación fina — staff iniciante (soporte) no debería tener ban, líder de evento necesita setSkin y giveMoney pero no setMoney infinito, y así sucesivamente.
Detén el servidor para editar acl.xml con seguridad:
sudo systemctl stop mtasaAbre el archivo en el editor:
sudo nano /opt/mtasa/mods/deathmatch/acl.xmlAgrega un grupo Support con alcance restringido. Inserta antes del </acl> final del archivo:
<group name="Support">
<object name="user.soporte1"/>
<acl name="Support"/>
<acl name="RPC"/>
</group>A continuación, define el ACL Support con los derechos mínimos. Busca el bloque <acl name="Moderator"> y agrega uno nuevo justo después:
<acl name="Support">
<right name="command.kick" access="true"/>
<right name="command.mute" access="true"/>
<right name="command.unmute" access="true"/>
<right name="command.warn" access="true"/>
<right name="resource.admin" access="true"/>
<right name="general.ModifyOtherObjects" access="false"/>
</acl>La directiva general.ModifyOtherObjects="false" es crítica — sin ella, cualquier cargo con acceso al panel admin puede promover/remover a otros usuarios, incluso escalar a Admin.
general.ModifyOtherObjects permite a un usuario editar permisos de otros usuarios vía panel admin. Concédelo SOLO al grupo Admin de máxima confianza. Soporte, moderadores y eventos NUNCA deben tener ese derecho — de lo contrario, cualquiera de ellos puede auto-promoverse a Admin.
Guarda el archivo (Ctrl+O, Enter, Ctrl+X en nano) y levanta el servidor:
sudo systemctl start mtasaVerifica en el log que el acl.xml cargó sin error de parsing:
sudo journalctl -u mtasa -n 50 --no-pagerBusca líneas como ACL loaded successfully o ausencia de ACL parse error.
Asignar cuentas a los grupos correctos
Con los grupos definidos, falta poblarlos. Crea las cuentas de los demás miembros y asigna cada uno al grupo apropiado.
En la consola (o in-game con /), crea cada cuenta nueva:
addaccount moderador1 ContrasenaFuerte001!
addaccount moderador2 ContrasenaFuerte002!
addaccount soporte1 ContrasenaFuerte003!Asigna cada cuenta al grupo correspondiente:
aclgroup add Moderator user.moderador1
aclgroup add Moderator user.moderador2
aclgroup add Support user.soporte1Cada comando edita acl.xml en runtime y persiste. Confirma con aclgroup list — debes ver las cuentas distribuidas en los grupos correctos.
No reutilices contraseñas entre cuentas de staff. Si una cuenta se filtra (phishing, reúso en foro, leak de base de datos), todas las demás quedan comprometidas. Considera una herramienta como Bitwarden o KeePassXC para que el equipo gestione credenciales.
Verificar permisos in-game
La configuración solo vale si el comportamiento real coincide con el diseño.
Conéctate al servidor con cada cuenta de prueba y autentícate:
/login moderador1 ContrasenaFuerte001!Debes recibir el mensaje You successfully logged in as moderador1 en el chat. Abre el panel admin con /admin o la tecla P — el panel debe aparecer solo con las pestañas y botones que el ACL del grupo permite.
Prueba cada permiso concedido y cada permiso DENEGADO. Para Support, por ejemplo:
- Intenta
kicka otro player → debe funcionar - Intenta
bana otro player → debe fallar conAccess denied - Intenta abrir la pestaña de gestión de admins → debe estar ausente o bloqueada
Si algo permite lo que no debería, revisa el ACL en el acl.xml — probablemente un <right> extra se coló o un grupo hereda más de lo debido.
Resolución de problemas
El login funciona pero no tengo permiso de admin
La cuenta fue creada pero no está en ningún grupo con poder. Agrégala con aclgroup add Admin user.tucuenta en la consola y prueba de nuevo.
El panel admin abre pero los botones están grises
El resource admin está accesible pero el ACL de tu grupo no tiene general.ModifyOtherObjects ni derechos suficientes en command.*. Verifica en el acl.xml que tu grupo de admin tenga los ACLs Admin y Moderator listados.
Error ACL parse error en el log
El acl.xml tiene XML inválido — tag mal cerrada, atributo sin comillas, carácter reservado suelto. Usa un validador XML antes de levantar el servidor. El comando xmllint --noout /opt/mtasa/mods/deathmatch/acl.xml (instalado con sudo apt install libxml2-utils) apunta a la línea exacta del problema.
Los cambios en acl.xml desaparecen tras reiniciar
Editaste el archivo con el servidor corriendo. MTA reescribe acl.xml periódicamente y sobrescribe cambios manuales. Siempre detén el servidor antes de editar a mano, o usa los comandos aclgroup/aclrights en la consola que persisten correctamente.
Próximos pasos
Con la ACL configurada, vale endurecer otras capas: activar <password> en mtaserver.conf para que nadie entre sin autorización, configurar acl.xml con <right name="resource.runcode" access="false"/> en el grupo Everyone (el resource runcode permite ejecución remota de Lua y es un vector crítico si se expone), e invertir en log de moderación vía un resource personalizado que registre todas las acciones del staff.
Si estás corriendo esto a escala — comunidad activa con varios moderadores simultáneos — un VPS Hostini con IP brasileño y protección contra ataques volumétricos asegura que tu infraestructura aguante un evento RP lleno sin oscilar. Conoce los planes en /jogos.
Preguntas frecuentes
¿Cuál es la diferencia entre ACL y Admin en MTA:SA?
ACL (Access Control List) es el sistema que define quién puede hacer qué — grupos, objetos y permisos granulares por resource. Admin es el resource oficial (`admin`) que provee interfaz in-game para moderar jugadores. ACL es la capa de autorización; admin es solo uno de los resources que consume esa capa.
¿Puedo tener varios niveles de admin con permisos diferentes?
Sí. Crea grupos separados en `acl.xml` (ej.: `Admin`, `Moderator`, `Support`) y asigna ACLs distintos a cada grupo. Cada ACL tiene su propio conjunto de `<right>` permitiendo o denegando acciones. Un moderador, por ejemplo, puede recibir `kick` y `mute` pero no `ban` ni `setMoney`.
¿Por qué mi cuenta creada vía `addaccount` no recibe permiso de admin automáticamente?
Crear una cuenta solo registra las credenciales. Necesitas agregar la cuenta al grupo correspondiente vía `aclgroup add Admin user.nombredelacuenta` en la consola, o editar manualmente `<object name="user.nombredelacuenta">` dentro del grupo en el `acl.xml`. Sin eso, el login funciona pero la cuenta no hereda ningún permiso.
¿Es seguro editar `acl.xml` con el servidor en ejecución?
La edición directa del archivo durante runtime no es recomendable — MTA reescribe `acl.xml` periódicamente y puede sobrescribir tus cambios. Detén el servidor antes de editar manualmente, o usa los comandos `aclrequest`, `aclgroup` y `aclrights` en la consola para cambios en runtime, que persisten correctamente.
¿Cómo bloqueo el resource `admin` para jugadores comunes?
En el grupo `Everyone` (que cubre a todo usuario no autenticado), asegúrate de que no haya `<right name="resource.admin" access="true"/>`. Por defecto ya está bloqueado, pero vale auditarlo. Solo grupos explícitos como `Admin` deben tener `<right name="resource.admin" access="true"/>`.
¿Qué hago si me quedo fuera del admin por un error en el `acl.xml`?
Detén el servidor (`Ctrl+C` o `systemctl stop mtasa`), edita `acl.xml` manualmente restaurando el grupo `Admin` con `<right name="general.ModifyOtherObjects" access="true"/>` y agrega tu cuenta como object. Levanta el servidor de nuevo y revalida con `/login` in-game.