Configurer les permissions ACE sur votre serveur FiveM

Qu’est-ce que le système de permissions ACE FiveM ?

Les permissions ACE FiveM constituent le mécanisme natif de contrôle d’accès de FXServer. Elles permettent de déterminer si un joueur, un groupe ou une ressource peut utiliser une commande ou une fonctionnalité précise.

ACE signifie Access Control Entry. Une entrée ACE associe :

Un principal
+ un objet de permission
+ une décision allow ou deny

Exemple :

add_ace group.moderator command.clientkick allow

Cette ligne autorise les membres de group.moderator à utiliser l’objet de permission command.clientkick.

Le système ACE est distinct des groupes internes d’ESX, de QBCore ou de txAdmin. Un joueur peut être administrateur dans txAdmin sans appartenir automatiquement à group.admin dans ACE.

Inversement, ajouter un joueur à group.admin ne lui attribue pas nécessairement un rôle ESX ou QBCore.

Une permission ACE protège uniquement une commande ou une fonctionnalité si la ressource concernée consulte réellement cette permission.

Comprendre les principals, les objets et les décisions

Le vocabulaire ACE repose sur trois éléments.

Élément	Fonction	Exemple
Principal	Identité qui reçoit ou hérite d’un droit	group.admin
Objet	Permission testée par FiveM ou une ressource	command.restart
Décision	Autorisation ou refus	allow ou deny

Les principals

Un principal peut représenter :

• un groupe ;
• un joueur identifié ;
• une ressource ;
• tous les utilisateurs.

Exemples :

group.admin
group.moderator
identifier.license:xxxxxxxx
resource.nom_de_la_ressource
builtin.everyone

builtin.everyone représente tous les joueurs. Il doit être utilisé avec une extrême prudence.

Les objets

Les objets de permission peuvent correspondre à des commandes :

command.say
command.clientkick
command.restart
command.ensure

Une ressource peut aussi créer son propre espace de permissions :

vMenu.Staff
vMenu.OnlinePlayers.Menu
monserveur.staff.reports
monserveur.vip.queue

L’objet personnalisé n’a d’effet que si une ressource le vérifie avec le mécanisme ACE.

Utiliser add_ace et add_principal

Les deux commandes essentielles sont :

add_ace
add_principal

Attribuer une permission avec add_ace

Syntaxe :

add_ace [principal] [objet] [allow|deny]

Exemple :

add_ace group.moderator command.clientkick allow

Pour autoriser une permission personnalisée :

add_ace group.moderator monserveur.staff.reports allow

Pour interdire une commande précise à un groupe qui hérite d’un droit plus large :

add_ace group.admin command.quit deny

Évitez toutefois de multiplier les règles deny. Une organisation basée sur des permissions explicitement accordées est généralement plus simple à auditer.

Rattacher un membre avec add_principal

Syntaxe :

add_principal [principal_enfant] [principal_parent]

Exemple :

add_principal identifier.license:VOTRE_IDENTIFIANT group.admin

Le joueur identifié hérite alors des permissions de group.admin.

Pour créer un héritage entre deux groupes :

add_principal group.admin group.moderator

Cette ligne signifie :

group.admin hérite de group.moderator

L’ordre est important. Le premier principal est l’enfant qui reçoit les droits du second.

Utiliser un fichier dédié

Vous pouvez placer les permissions directement dans server.cfg, mais un fichier séparé est plus lisible.

Créez par exemple :

permissions.cfg

Puis ajoutez dans server.cfg :

exec permissions.cfg

Placez cette ligne avant le démarrage des ressources qui utilisent les permissions :

exec permissions.cfg

ensure vMenu
ensure mon_script_admin

Pour vMenu, le fichier peut aussi être chargé directement depuis la ressource selon son installation :

exec @vMenu/config/permissions.cfg
ensure vMenu

Identifier correctement un joueur

FiveM peut exposer plusieurs types d’identifiants :

Type	Exemple de principal	Remarque
Licence Rockstar	identifier.license:...	Couramment utilisé pour les droits persistants
Licence secondaire	identifier.license2:...	Peut être identique à license selon le contexte
Compte Cfx.re	identifier.fivem:123456	Lié au compte Cfx.re
Discord	identifier.discord:123456789	Disponible seulement lorsque l’identifiant est exposé
Steam	identifier.steam:110000...	Dépend de la présence de l’identifiant Steam
Adresse IP	identifier.ip:192.0.2.10	Instable et déconseillé pour les permissions

Pour un rôle durable, préférez généralement un identifiant license: ou fivem: récupéré directement depuis le serveur.

L’identifiant Discord peut être pratique pour certaines intégrations, mais il peut être absent selon la connexion du joueur et la configuration utilisée. Ne dépendez pas exclusivement de Discord sans avoir testé le comportement réel.

L’adresse IP est un mauvais choix :

• elle peut changer ;
• plusieurs joueurs peuvent partager la même adresse ;
• un VPN modifie l’adresse visible ;
• elle ne représente pas durablement un compte.

Récupérer les identifiants

Vous pouvez consulter les informations d’un joueur depuis txAdmin ou utiliser une ressource serveur qui affiche les valeurs retournées par FiveM.

Une sortie peut ressembler à :

license:4ab12...
license2:4ab12...
fivem:1234567
discord:123456789012345678
steam:110000112345678
ip:192.0.2.10

Copiez uniquement l’identifiant nécessaire dans votre configuration :

add_principal identifier.license:4ab12... group.moderator

Ne publiez jamais la liste complète des identifiants de vos joueurs dans un dépôt public, une capture d’écran ou un salon Discord accessible à tous.

Créer des groupes hiérarchisés

Une hiérarchie simple évite de répéter les mêmes permissions.

Exemple :

Administrateur
    ↓ hérite de
Modérateur
    ↓ hérite de
VIP

Configuration :

# Héritage
add_principal group.admin group.moderator
add_principal group.moderator group.vip

# Droits VIP
add_ace group.vip monserveur.queue.priority allow

# Droits modérateur
add_ace group.moderator monserveur.staff.reports allow
add_ace group.moderator command.clientkick allow
add_ace group.moderator command.say allow

# Droits administrateur
add_ace group.admin command.restart allow
add_ace group.admin command.ensure allow
add_ace group.admin command.stop allow

Rattachez ensuite les membres :

add_principal identifier.license:LICENCE_ADMIN group.admin
add_principal identifier.license:LICENCE_MOD group.moderator
add_principal identifier.license:LICENCE_VIP group.vip

L’administrateur reçoit ses droits propres, ceux du groupe modérateur et ceux du groupe VIP.

N’utilisez pas cette syntaxe incorrecte :

add_principal group.admin group.moderator group.vip

add_principal accepte un enfant et un parent par ligne.

Évitez add_ace group.admin command allow sauf nécessité réelle. Cette permission donne accès à un ensemble extrêmement large de commandes serveur.

Intégrer ACE avec vMenu, ESX et QBCore

vMenu

vMenu utilise directement le système ACE natif. Ses permissions commencent généralement par :

vMenu.

Exemple :

add_ace group.moderator "vMenu.Staff" allow
add_ace group.moderator "vMenu.OnlinePlayers.Menu" allow
add_ace group.moderator "vMenu.OnlinePlayers.Spectate" allow
add_ace group.moderator "vMenu.OnlinePlayers.Kick" allow

N’accordez pas une permission globale .All si vous souhaitez ensuite exclure certaines actions. Pour vMenu, il est généralement préférable d’autoriser uniquement les fonctions nécessaires.

Consultez le guide consacré à vMenu sur FiveM.

ESX et QBCore

ESX et QBCore disposent généralement de leurs propres systèmes de groupes, métiers et permissions.

Exemples conceptuels :

Groupe ESX : admin
Permission ACE : group.admin
Permission txAdmin : players.kick

Ces trois notions ne sont pas automatiquement synchronisées.

Certaines ressources convertissent ou rattachent dynamiquement un groupe du framework à un principal ACE. Dans ce cas, la ressource doit utiliser des commandes comme :

add_principal
remove_principal

ou vérifier les permissions avec IsPlayerAceAllowed.

Avant de modifier votre configuration, consultez la documentation de la ressource. Ne supposez pas qu’un groupe nommé admin possède automatiquement tous les droits ACE.

Pour installer un framework, consultez le guide installer ESX ou QBCore.

Tester et sécuriser les permissions

Utilisez la console FXServer ou txAdmin pour tester une permission :

test_ace group.moderator command.clientkick

Vous pouvez également tester un identifiant :

test_ace identifier.license:VOTRE_IDENTIFIANT command.clientkick

Listez les ACE configurées :

list_aces

Listez les héritages :

list_principals

Avant de redémarrer le serveur :

1. conservez un accès à la console txAdmin ;
2. vérifiez votre propre identifiant ;
3. testez les droits du groupe ;
4. testez également une action qui doit être refusée ;
5. évitez de modifier plusieurs niveaux simultanément.

N’accordez jamais command allow à builtin.everyone. Tous les joueurs pourraient accéder à des commandes serveur critiques si celles-ci leur sont accessibles.

Appliquez le principe du moindre privilège : un modérateur chargé des signalements n’a pas besoin de redémarrer des ressources ou d’arrêter le serveur.

Les permissions contribuent à la sécurité, mais ne remplacent pas un système Anti-Cheat ni la validation serveur des événements. Consultez le guide sur l’Anti-Cheat FiveM.

Dépanner une permission qui ne fonctionne pas

Le fichier n’est pas chargé

Vérifiez la présence de :

exec permissions.cfg

Contrôlez son emplacement et son nom exact. Sous Linux, Permissions.cfg et permissions.cfg sont deux noms différents.

Le mauvais identifiant est utilisé

Comparez l’identifiant configuré avec celui réellement retourné lors de la connexion :

identifier.license:...

N’ajoutez pas de préfixe supplémentaire et ne confondez pas :

license:
identifier.license:

Dans add_principal, la forme attendue est :

identifier.license:VALEUR

L’héritage est inversé

Mauvais sens :

add_principal group.moderator group.admin

Cette ligne ferait hériter le modérateur des permissions administrateur.

Sens généralement souhaité :

add_principal group.admin group.moderator

Une permission large masque votre logique

Avec vMenu, une permission comme :

add_ace group.admin "vMenu.OnlinePlayers.All" allow

autorise toutes les actions du sous-menu. Retirer une action individuelle ne suffit alors pas : il faut retirer .All et accorder précisément les actions souhaitées.

Le framework utilise son propre système

Si une commande ESX ou QBCore ignore ACE, vérifiez son système d’autorisation interne. Une permission ACE n’a aucun effet si le script ne l’interroge pas.

Pour administrer et surveiller le serveur pendant vos tests, consultez le guide démarrer avec txAdmin.

En résumé

• Les permissions ACE FiveM contrôlent nativement l’accès aux commandes et fonctions qui les vérifient.
• Un principal peut représenter un joueur, un groupe ou une ressource.
• add_ace attribue une permission à un principal.
• add_principal crée une relation d’héritage entre deux principals.
• Le premier argument de add_principal est l’enfant ; le second est le parent.
• Placez les permissions dans server.cfg ou un fichier dédié chargé avec exec.
• Préférez généralement identifier.license: ou identifier.fivem: pour les rôles persistants.
• Évitez les permissions basées sur l’adresse IP.
• Ne publiez jamais les identifiants complets de vos joueurs.
• Organisez des groupes admin, moderator et vip avec un héritage clair.
• vMenu utilise directement des objets ACE commençant par vMenu..
• ESX, QBCore, txAdmin et ACE restent des systèmes distincts sauf intégration explicite.
• Testez les droits avec test_ace, list_aces et list_principals.
• N’accordez jamais command allow à builtin.everyone.
• Gardez un accès console de secours pendant les modifications.
• Appliquez le principe du moindre privilège à chaque groupe.
• Pour configurer les permissions ACE FiveM sur un hébergement en France avec stockage NVMe, protection Anti-DDoS L3/L4/L7 incluse, panel de gestion et support francophone, découvrez les offres FiveM TalCloud.