FiveM ACE Permissions einrichten: Gruppen, Identifier und Rechteprüfung im eigenen Script

FiveM ACE Permissions sind das eingebaute Rechtesystem von FXServer: Mit add_ace erlaubst oder verbietest du einer Gruppe ein Recht, mit add_principal ordnest du Spieler-Identifier oder andere Gruppen dieser Gruppe zu. In deinen Scripts prüfst du die Rechte anschließend serverseitig mit IsPlayerAceAllowed. Am saubersten legst du alles in einer eigenen permissions.cfg ab, die du aus der server.cfg lädst.

Dieser Beitrag zeigt dir den Aufbau einer belastbaren Rechtestruktur, die passenden Identifier, die Prüfung im Lua-Code und die Fehler, die in der Praxis am häufigsten zu offenen Admin-Befehlen führen.

Wie funktioniert das ACE-System in FiveM?

ACE steht für Access Control Entry. Das System kennt drei Bausteine, die du auseinanderhalten solltest.

• Principal: Wer bekommt ein Recht? Das kann ein Spieler-Identifier sein (identifier.license:...), eine Gruppe (group.admin) oder eine Ressource (resource.meinscript).
• Object: Worauf bezieht sich das Recht? Eingebaute Befehle heißen command.name, eigene Rechte kannst du frei benennen, zum Beispiel srv.revive.
• Zustand: allow oder deny.

Principals lassen sich verschachteln. Wenn du add_principal group.admin group.mod schreibst, erbt group.admin alle Rechte von group.mod. Dadurch musst du jedes Recht nur einmal auf der niedrigsten passenden Stufe vergeben.

Objekte sind hierarchisch über Punkte aufgebaut. Ein Recht auf command gilt für alle Befehle, ein Recht auf srv für alle Objekte, die mit srv. beginnen. Ein explizites deny auf ein Unterobjekt schlägt dabei ein allgemeines allow. Genau das nutzt du, um gefährliche Befehle gezielt auszunehmen.

Welchen Identifier solltest du für Admins verwenden?

Der Identifier entscheidet, ob ein Recht dauerhaft am richtigen Menschen hängt. FXServer stellt mehrere Typen bereit, die du in der Konsole oder in txAdmin pro Spieler siehst.

• identifier.license: ist an die Rockstar-Lizenz gebunden und für jeden Spieler vorhanden. Für die meisten Server die solideste Wahl.
• identifier.fivem: hängt am Cfx.re-Konto und ist nur vorhanden, wenn der Spieler eingeloggt ist.
• identifier.discord: ist praktisch, wenn deine Teamverwaltung ohnehin über Discord läuft, setzt aber voraus, dass der Spieler Discord verbunden hat.
• identifier.steam: funktioniert nur, wenn Steam läuft und ein Steam-Web-API-Key gesetzt ist.

IP-Adressen solltest du nicht verwenden. Sie ändern sich und können bei geteilten Anschlüssen falsche Personen berechtigen. Wenn du ganz sicher gehen willst, vergibst du kritische Gruppen über die Lizenz und nutzt Discord nur zusätzlich, etwa für Support-Rollen.

FiveM ACE Permissions einrichten: Schritt für Schritt

1. Lege im Ordner deiner server.cfg eine Datei permissions.cfg an. So bleibt die Rechteverwaltung von Endpunkten, Lizenzschlüssel und Ressourcenliste getrennt.
2. Definiere zuerst die Gruppenhierarchie, dann die Rechte pro Gruppe, zuletzt die Zuordnung der Spieler.
3. Lade die Datei in der server.cfg mit exec permissions.cfg, am besten vor den ensure-Zeilen, damit die Rechte stehen, bevor Ressourcen Befehle registrieren.
4. Starte den Server neu und kontrolliere die Einträge in der Live-Konsole mit list_aces und list_principals.
5. Teste jedes Recht mit einem Account der jeweiligen Stufe, nicht nur mit deinem eigenen Superadmin-Account.

Eine vollständige permissions.cfg mit drei Stufen sieht so aus:

# ---------- Hierarchie ----------
# superadmin erbt von admin, admin erbt von mod
add_principal group.superadmin group.admin
add_principal group.admin group.mod

# ---------- Rechte: Moderatoren ----------
add_ace group.mod srv.kick allow
add_ace group.mod srv.spectate allow
add_ace group.mod srv.teleport allow

# ---------- Rechte: Admins ----------
add_ace group.admin srv.revive allow
add_ace group.admin srv.giveitem allow
add_ace group.admin srv.vehicle allow

# ---------- Rechte: Superadmins ----------
add_ace group.superadmin command allow
add_ace group.superadmin command.quit deny

# ---------- Team-Zuordnung ----------
add_principal identifier.license:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa group.superadmin
add_principal identifier.license:bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb group.admin
add_principal identifier.discord:123456789012345678 group.mod

Die eigenen Rechte unter srv. sind bewusst von den eingebauten command.-Objekten getrennt. So kannst du sie in deinen Scripts gezielt prüfen, ohne dass ein Teammitglied automatisch Zugriff auf jeden Konsolenbefehl bekommt.

Rechte im eigenen Script prüfen

Es gibt zwei Wege, einen Befehl abzusichern. Der erste ist der Parameter restricted von RegisterCommand. Steht er auf true, darf nur ausführen, wer das ACE command.befehlsname besitzt. Das ist schnell, aber grob: Du kannst keine eigene Fehlermeldung ausgeben und nicht nach Zielspieler oder Kontext unterscheiden.

Flexibler ist die explizite Prüfung im Handler:

RegisterCommand('revive', function(source, args)
    local src = source
    if src == 0 then return end -- Aufruf aus der Konsole ignorieren

    if not IsPlayerAceAllowed(src, 'srv.revive') then
        TriggerClientEvent('chat:addMessage', src, {
            args = { 'System', 'Dafür fehlt dir die Berechtigung.' }
        })
        return
    end

    local target = tonumber(args[1]) or src
    if not GetPlayerName(target) then return end

    TriggerClientEvent('srv:revive', target)
end, false)

Noch wichtiger ist die Prüfung bei Net-Events. Ein Admin-Menü, das auf dem Client nur für Berechtigte sichtbar ist, schützt nichts, solange das zugehörige Event auf dem Server jeden Aufruf annimmt. Modder lösen Events direkt aus, ohne dein Menü je zu öffnen.

RegisterNetEvent('srv:adminTeleport', function(coords)
    local src = source
    if not IsPlayerAceAllowed(src, 'srv.teleport') then
        print(('[ACE] %s (%s) ohne srv.teleport'):format(GetPlayerName(src), src))
        return
    end
    if type(coords) ~= 'table' or not coords.x then return end

    SetEntityCoords(GetPlayerPed(src), coords.x + 0.0, coords.y + 0.0, coords.z + 0.0)
end)

Clientseitige Prüfungen mit IsAceAllowed taugen nur dafür, Menüpunkte ein- oder auszublenden, die eigentliche Rechteprüfung gehört immer in den Server-Handler. Dasselbe Prinzip beschreibt der Beitrag zum eigenen Job-Script mit serverseitiger Validierung ausführlicher für Jobaktionen und Auszahlungen.

Fehlgeschlagene Prüfungen solltest du nicht nur in der Konsole ausgeben. Ein Spieler, der wiederholt Admin-Events ohne Recht auslöst, ist ein klares Signal. Wenn du solche Versuche in einen Team-Channel schicken willst, hilft dir die Anleitung zu sicheren Server-Logs per Discord-Webhook mit Rate-Limit-Queue.

Rechte zur Laufzeit ändern, ohne Neustart

Die permissions.cfg wird nur beim Start gelesen. Für kurzfristige Änderungen kannst du die Befehle direkt in der Live-Konsole oder in txAdmin eingeben:

add_principal identifier.license:cccccccccccccccccccccccccccccccccccccccc group.mod
remove_principal identifier.license:cccccccccccccccccccccccccccccccccccccccc group.mod

Diese Änderungen gelten sofort, sind aber nach dem nächsten Neustart verschwunden. Trage dauerhafte Änderungen deshalb immer zusätzlich in die Datei ein.

Soll ein eigenes Admin-Script Rechte per ExecuteCommand vergeben, braucht die Ressource selbst ein ACE. Ressourcen sind ebenfalls Principals:

add_ace resource.mein_adminscript command.add_principal allow
add_ace resource.mein_adminscript command.remove_principal allow

Vergib Ressourcen nur genau die Befehle, die sie brauchen. Ein pauschales add_ace resource.xyz command allow bedeutet, dass jede Lücke in diesem Script zum Vollzugriff auf die Konsole wird.

ACE und Framework-Rechte: Wie passt das zusammen?

ESX, QBCore und QBox bringen eigene Admin-Konzepte mit, und die Verbindung zum ACE-System unterscheidet sich je nach Framework und Version. In ESX wird die Gruppe eines Spielers typischerweise in der Datenbank gespeichert. QBCore-Vorlagen arbeiten dagegen mit ACE-Gruppen wie qbcore.god, qbcore.admin und qbcore.mod, die in der server.cfg per Vererbung verknüpft werden.

Prüfe deshalb in der Dokumentation und Konfiguration deines Frameworks, welche Quelle für Admin-Befehle maßgeblich ist. Ein häufiges Problem entsteht, wenn beide Systeme parallel gepflegt werden und auseinanderlaufen: Ein ehemaliges Teammitglied ist aus der Datenbankgruppe entfernt, steht aber noch als add_principal in der Konfiguration. Lege fest, welches System führend ist, und halte das zweite synchron.

Auch txAdmin hat eine eigene Admin-Verwaltung für das Webpanel und das In-Game-Menü. Sie ist von deinen ACE-Gruppen unabhängig. Wer in txAdmin Spieler kicken darf, hat damit nicht automatisch srv.revive in deinen Scripts und umgekehrt.

Typische Fehler, die Admin-Befehle öffnen

• Wildcard ohne deny: add_ace group.admin command allow gibt Zugriff auf alle Befehle, auch auf quit und auf add_principal. Wer dieses Recht hat, kann sich selbst und andere in jede Gruppe heben. Nutze die Wildcard höchstens für die oberste Stufe und ergänze gezielte deny-Einträge.
• Vererbung verdreht: add_principal group.mod group.admin lässt Moderatoren alle Admin-Rechte erben. Merke dir: Zuerst steht das Kind, danach die Gruppe, von der es erbt.
• Tippfehler im Identifier: Ein fehlendes Zeichen erzeugt keine Fehlermeldung, das Recht greift einfach nicht. Kopiere Identifier immer aus der Konsole oder aus txAdmin.
• Prüfung nur auf dem Client: Siehe oben. Jeder Server-Handler mit Admin-Wirkung braucht seine eigene Abfrage.
• Vergessene Altlasten: Gehe die Team-Zuordnung bei jedem Teamwechsel durch. Kommentare mit Namen und Datum neben jeder add_principal-Zeile machen das deutlich einfacher.

Rechte und Teamrollen über ein Panel verwalten

Bei kleinen Teams reicht die permissions.cfg völlig. Wächst das Team, wird die Pflege von Hand fehleranfällig, weil Rollen, Zuständigkeiten und Dokumentation an verschiedenen Stellen liegen. Dann lohnt sich eine Weboberfläche, in der die Teamstruktur zentral gepflegt wird.

Bei Web-Services gibt es dafür zum Beispiel das Support Control Panel mit Rollen, Supportfällen und Akten für die Teamorganisation sowie das Game Control Panel zur Verwaltung von Spielern, Jobs und Items mit Live-Bridge zum laufenden Server. Beide ersetzen nicht die serverseitige ACE-Prüfung in deinen Scripts, sie nehmen dir aber organisatorische Arbeit rund ums Team ab. Ob ein Panel zu deinem Setup und Framework passt, solltest du vorab anhand der jeweiligen Produktseite prüfen.

FAQ

Wo trage ich ACE Permissions in FiveM ein?

Grundsätzlich in der server.cfg. Übersichtlicher ist eine separate permissions.cfg, die du mit exec permissions.cfg vor den ensure-Zeilen lädst. Für Tests kannst du die Befehle auch in der Live-Konsole eingeben, dann gelten sie aber nur bis zum nächsten Neustart.

Was ist der Unterschied zwischen add_ace und add_principal?

add_ace verbindet einen Principal mit einem Recht, also zum Beispiel group.admin mit srv.revive. add_principal verbindet zwei Principals, etwa einen Spieler-Identifier mit einer Gruppe oder eine Gruppe mit einer anderen, von der sie erben soll.

Warum funktioniert mein Admin-Recht nicht?

Meist liegt es an einem falschen Identifier, an verdrehter Vererbung oder an einem deny, das ein allow überschreibt. Kontrolliere mit list_principals und list_aces, ob deine Einträge tatsächlich geladen wurden, und vergleiche den Identifier zeichengenau mit dem in der Konsole angezeigten Wert.

Kann ich ACE-Rechte an Discord-Rollen koppeln?

Nicht direkt, FXServer kennt nur den Discord-Identifier eines Spielers, nicht seine Rollen. Für eine Kopplung brauchst du ein Script oder einen Bot, der die Rolle abfragt und beim Verbinden per add_principal die passende Gruppe setzt. Die Ressource benötigt dafür selbst das ACE auf command.add_principal.