You probably know you can give yourself and your friends OP status on your server. OPs can use any commands; they can change gamemodes, broadcast messages, and generally do whatever is possible with the plugins you have installed. They're basically super-administrators, with no checks on their capabilities.
If you're only running a small server for friends, using OP is perfectly fine. If you only give OP to trusted friends, it's all fine.
But suppose you want to expand your server. You want to have builders, moderators, admins, and all the rest. Obviously, you don't want builders to be able to stop the server with /stop or a similar command.
The solution is to use a structured system of defined access levels. In this system, each player has a fixed list of capabilities they can use, including access to commands and features.
Since this is a tutorial, we'll start with a very basic example. You want to be dictator on your server and have sole access to /gamemode. You have a friend whom you wouldn't give /gamemode, but whom you would give /tp.
In Minecraft, we do this with text-based capabilities:
The minecraft.command.gamemode capability lets players use /gamemode.
The minecraft.command.teleport capability lets players use /tp.
So, you have to find a way to give yourself the minecraft.command.gamemode capability,
and your friend the minecraft.command.teleport, while everyone else gets no special capabilities.
(I'll describe in detail how to add capabilities to a player later, let's stick to the concepts for now)
You manage to grant yourself the minecraft.command.gamemode capability and your friend
the minecraft.command.teleport capability. This all works fine, but you start trusting more players,
and you want to give them the minecraft.command.teleport capability also.
You assign all your trusted players the minecraft.command.teleport capability. A few days later,
you now have 34 players who can use the minecraft.command.teleport capability. Your server grew
quite a bit!
But, you now want to give those 34 players the minecraft.command.setblock capability also.
How do you do this in an efficient manner, without doing the same thing 34 times?
The solution is to use groups to define capabilities, and assign players into groups. When a player is in the group, the player receives all of the capabilities of that group. Instead of giving capabilities to players, you give capabilities to groups, and the groups give their capabilities to the players in the groups.
If you put 34 players into the "moderator" group, and add the minecraft.command.setblock capability to the group,
it will be the same effect as if you had given every one of those 34 players the capability!
You can think of groups in terms of a tree-like structure:
admin:
capabilities:
- "minecraft.command.teleport"
- "minecraft.command.setblock"
users:
- "Player1"
- "A248"As you can see, all of the players listed in the users section have the capabilities listed in the capabilities section. In this case, Player1 and A248 are members of the "admin" group so they have minecraft.command.teleport and minecraft.command.setblock.
You can also use inheritance to further streamline capabilities management. With inheritance, you can make the group "admin" have all of the capabilities of the group "mod" automatically, in addition to admin group's unique capabilities.
admin:
capabilities:
- "minecraft.command.teleport"
- "minecraft.command.setblock"
users:
- "Player1"
- "A248"
inherits-from:
- helper
helper:
capabilities:
- "minecraft.command.weather"
users:
- "Player3"If a group inherits from another group, the second group is said to be a parent group. The first group is a child group. In this example, Player3 is a member of the "helper" group, so they have the minecraft.command.weather capability. Player1 and A248 are members of the "admin" group, so they have the minecraft.command.teleport capability, the minecraft.command.setblock capability, AND the minecraft.command.weather capability because of inheritance.
A capability is a permission. Permissions are capabilities. I just used a different word so that you could build a good conception of the idea from scratch. Congratulations, you have just learned permissions!
There are several permissions plugins out there to choose from. Many of them are outdated, so be sure not to choose a permissions plugin from 2014, unless you know what you're doing. Just google "minecraft permission plugin" to get started!
Each permission plugin will have:
- A command to create/define a group.
- A command to add a player to a group.
- A command to remove a player from a group.
- A command to add a permission to a group.
- A command to remove a permission from a group.
For your information, there is a way to manage permissions without using a permissions plugin. But doing so requires you to manually configure your permissions, and restart your server whenever you make any changes. Permissions plugins will make your life a lot easier.
Minecraft plugins, on Spigot, BungeeCord, or Sponge, use permissions to define specific capabilities that players can use (see why I used the word capabilities?). You may have a banning plugin which has the following permissions listed on its plugin page:
banplugin.ban - ban a player permanently
banplugin.tempban - ban a player temporarily
banplugin.mute - mute a player permanently
banplugin.tempmute - tempmute a player permanently
banplugin.kick - kick a player from the server
It's pretty much obvious that if you give your "mod" group the banplugin.ban permission, then all players in the "mod" group can ban other players!
Most advanced permissions plugins allow wildcard permissions. With wildcard permissions, you can assign many permissions with 1 command.
If you grant a group the banplugin.* permission, that group will have any permission which starts with "banplugin."
It's really that simple. Keep in mind, though, that while wildcard permissions are more convenient, they mean less flexibility. If you grant the banplugin.* permission, you can't revoke the banplugin.mute permission. If you want moderators to do everything EXCEPT mute other players, you'll need to unassign the wildcard permission, and grant each individual permission you want to use.
Also, never give the * permission – it's almost as bad as OP.
On Spigot, some plugin permissions are given to players by default, as configured by plugin authors. This means you won't have to give players a specific permission when you install the plugin.
I don't like default permissions because I vastly prefer to have players' capabilities clearly well-defined by the permissions plugin. If I want a permission assigned, I will assign it myself.
If you don't want players to have a default permission, you have to negate the permission. On most permission plugins you can add a little "-" before the permission and give it to the player like that. For example, "-minecraft.command.say" will prevent players from using the /say command.