Bukkit Permissions Rant
Posted: Sun Aug 21, 2011 9:01 pm
We are currently using Permissions 3 for our Minecraft server, but it's just gone INACTIVE on the Bukkit forums. This means that it's been sitting around for a long time without an update, and there are no projected updates at the moment. I'm pointing this out because it may foreshadow a change in permissions plugins sometime after 1.8.
Here's the full story:
All of the permissions plugins are dying in favor of Bukkit's new permissions system. This would be good except for the fact that Bukkit's permissions system is complete crap.
Allow me to explain a few features, how they work, and how they compare between Bukkit Permissions and Permissions 3:
On the user end, you will likely notice nothing if I set it up properly, but this just makes my job harder. Expect things to break sometime between now and 1.8 because I can't guarantee our current permissions plugin will hold until then.
Here's the full story:
All of the permissions plugins are dying in favor of Bukkit's new permissions system. This would be good except for the fact that Bukkit's permissions system is complete crap.
Allow me to explain a few features, how they work, and how they compare between Bukkit Permissions and Permissions 3:
- Permissions 3:
The groups and users system for Permissions 3 is a complex multi-world solution to permissions. In past versions of Permissions, there was only one Permissions file: config.yml
When Bukkit released it's multi-world functionality, Permissions had to change and a multi-world system was created by specifying one permissions file per world and one global permissions file that the worlds would take permissions from. In Permissions 3, they decided to completely change things: They changed the per-world config files to per-world config folders, changed how worlds inherit global permission, and split groups and users into two separate files per world. This is where we are now.
With that bit of history out of the way, I can explain how it's all setup:
A group in Permissions 3 has several default settings setup something like this:Let's go down the list here:Code: Select all
Guest: default: true info: prefix: '' suffix: '' build: false inheritance: permissions: - lwc.blockinventory - cf.allowcommand - commandbook.motd - mywarp.warp.sign.use
"Guest:" - The group name
"default:" - Whether or not new players will be assigned to this group when they join.
"info:" - A grouping node (not permissions node) that holds special variables.
"prefix:" - Used by chat appearance plugins. This is usually placed before a player's name. This can contain color codes.
"suffix:" - Same as prefix, but is placed after the name.
"build:" - Whether or not the player is allowed to modify the world.
"inheritance:" - Allows the group to take permissions from another group.
"permissions:" - The heart of the plugin; Where permissions nodes go for the group.
As you can tell, this is the permissions setup for the Guest group. The nodes under permissions tell plugins how to respond to a group when a feature is used.
Guests can use the CFBanner check command, the /motd command from CommandBook, and warp signs from MyWarp. They also have a permissions node from LWC that disables their ability to use any block that has an inventory (chests, furnaces, and dispensers).
The permissions don't necessarily have to allow or deny a feature, as seen with lwc.blockinventory. They can even change how fast the player can go in a Minecart if the plugin wishes to control it.
Permissions are fairly easy to setup and they usually follow the standard "Plugin.featureset.feature" format. However, a wildcard can be specified to give all permissions under a certain plugin or set of features to a group. For instance, Moderators have the permissions node "myhome.*". The * basically tells Permissions that the Moderator group has every permission that myhome has to offer. This makes it very convenient for me because, in the case of plugins like Worldedit and Tele++, I don't have to add every single feature I want the moderators to have to their permissions list. Instead, I can give the Moderators "tpp.mod.*" and negate what I don't want, which brings me to my next topic: Node negation.
Node negation is a feature in Permissions 3 that allows me to take away otherwise permitted permissions. For instance, in the case of tpp.mod.*, I don't want the Moderators to have the Tele++ Mover tool. It's pretty useless. So, all I have to do is, instead of removing tpp.mod.* and adding every feature I want them to have, is add "-tpp.mod.mover" to the list after tpp.mod.* and permissions knows that Moderators don't have the tpp.mod.mover permission.
Users in Permissions 3 are a pretty simple concept. Basically a user can act as its own group in the way that permissions and variables can be individually defined for each. This means that if I want ModeratorA to be able to reload WorldGuard, but I don't want ModeratorB to be able to, I can add the permissions for the WorldGuard reload command to ModeratorA's user permissions list and I won't have to create a separate group for them.
Here is my Users entry for Permissions 3:Everything here should be pretty self-explanatory except for "groups:", but all you really need to understand about that is that Permissions 3 allows players to be a part of multiple groups at the same time. It works by combining the groups' permissions.Code: Select all
Foxtrot200: groups: - Admin permissions:
Note that even though my permissions node is left blank, the permissions from my group are still active. For curiosity's sake, the Admin group has the '*' permission, which gives me every permission any plugin can give me. This allows me to make certain that every plugin we have will work for me so I can properly set it up to work for everyone else. - Bukkit Permissions:
Groups in Bukkit Permissions work similarly to Permissions 3 and other permissions plugins in that they all use permissions nodes. The major differences are how they handle multi-world permissions and the obvious lack of in-built variable functionality (you have to get another plugin to add things like the prefix and suffix nodes).
Here is how the Member group looks in both Permissions 3 and Bukkit Permissions:
Permissions 3:Bukkit Permissions:Code: Select all
Member: default: false info: prefix: '&b' suffix: '&f' build: true inheritance: - Guest permissions: - craftbook.mech.* - jail.usercmd.jailstatus - lwc.protect - BlueTelePads.Create - BlueTelePads.Use - myhome.home.basic.* - myhome.home.soc.* - mywarp.warp.basic.* - mywarp.warp.soc.* - mywarp.warp.sign.* - commandbook.who - commandbook.motd - commandbook.intro - commandbook.rules - commandbook.time.check - commandbook.spawn - commandbook.call - commandbook.msg - commandbook.whereami - commandbook.whereami.compass - iConomy.access - iConomy.bank.* - iConomy.payment - jukebukkit.burn - bookworm.create - bookworm.write.own - bookworm.copy.own - bookworm.copy.others - bookworm.remove.own - bookworm.destroy.own - worldguard.region.flag.own.* - worldguard.region.info.* - worldguard.region.flag.flags.pvp.* - worldguard.region.flag.flags.build.* - worldguard.region.flag.flags.mob-damage.* - worldguard.region.flag.flags.mob-spawning.* - worldguard.region.flag.flags.lightning.* - worldguard.region.flag.flags.chest-access.* - worldguard.region.flag.flags.use.* - worldguard.region.flag.flags.vehicle-place.* - worldguard.region.flag.flags.snow-fall.* - worldguard.region.flag.flags.leaf-decay.* - worldguard.region.flag.flags.greeting.* - worldguard.region.flag.flags.farewell.* - SignShop.Signs.* - backpack.size9 - backpack.upgrade18 - backpack.upgrade27 - backpack.upgrade36 - backpack.upgrade45 - backpack.upgrade54 - backpack.nodrop - mywarp.warp.sign.*(Bukkit Permissions doesn't use separate files for multiple worlds)Code: Select all
Member: permissions: permissions.build: true worlds: world: craftbook.mech.*: true jail.usercmd.jailstatus: true lwc.protect: true BlueTelePads.Create: true BlueTelePads.Use: true myhome.home.basic.*: true myhome.home.soc.*: true mywarp.warp.basic.*: true mywarp.warp.soc.*: true mywarp.warp.sign.*: true commandbook.who: true commandbook.motd: true commandbook.intro: true commandbook.rules: true commandbook.time.check: true commandbook.spawn: true commandbook.call: true commandbook.msg: true commandbook.whereami: true commandbook.whereami.compass: true iConomy.access: true iConomy.bank.*: true iConomy.payment: true jukebukkit.burn: true bookworm.create: true bookworm.write.own: true bookworm.copy.own: true bookworm.copy.others: true bookworm.remove.own: true bookworm.destroy.own: true worldguard.region.flag.own.*: true worldguard.region.info.*: true worldguard.region.flag.flags.pvp.*: true worldguard.region.flag.flags.build.*: true worldguard.region.flag.flags.mob-damage.*: true worldguard.region.flag.flags.mob-spawning.*: true worldguard.region.flag.flags.lightning.*: true worldguard.region.flag.flags.chest-access.*: true worldguard.region.flag.flags.use.*: true worldguard.region.flag.flags.vehicle-place.*: true worldguard.region.flag.flags.snow-fall.*: true worldguard.region.flag.flags.leaf-decay.*: true worldguard.region.flag.flags.greeting.*: true worldguard.region.flag.flags.farewell.*: true SignShop.Signs.*: true backpack.size9: true backpack.upgrade18: true backpack.upgrade27: true backpack.upgrade36: true backpack.upgrade45: true backpack.upgrade54: true backpack.nodrop: true mywarp.warp.sign.*: true world_nether: craftbook.mech.*: true jail.usercmd.jailstatus: true lwc.protect: true BlueTelePads.Use: true commandbook.who: true commandbook.motd: true commandbook.intro: true commandbook.rules: true commandbook.time.check: true commandbook.call: true commandbook.msg: true commandbook.whereami: true commandbook.whereami.compass: true jukebukkit.burn: true worldguard.region.flag.own.*: true worldguard.region.info.*: true worldguard.region.flag.flags.pvp.*: true worldguard.region.flag.flags.build.*: true worldguard.region.flag.flags.mob-damage.*: true worldguard.region.flag.flags.mob-spawning.*: true worldguard.region.flag.flags.lightning.*: true worldguard.region.flag.flags.chest-access.*: true worldguard.region.flag.flags.use.*: true worldguard.region.flag.flags.vehicle-place.*: true worldguard.region.flag.flags.snow-fall.*: true worldguard.region.flag.flags.leaf-decay.*: true worldguard.region.flag.flags.greeting.*: true worldguard.region.flag.flags.farewell.*: true SignShop.Signs.*: true backpack.size9: true backpack.upgrade18: true backpack.upgrade27: true backpack.upgrade36: true backpack.upgrade45: true backpack.upgrade54: true backpack.nodrop: true survival: BlueTelePads.Use: true survival_nether: BlueTelePads.Use: true inheritance: - Guest
Now, this may not look like much, but you have to understand how Bukkit Permissions handles the permissions nodes. For one thing, there is no such thing as a global permission. Instead, plugins must define what is known as a parent permission. This parent permission is basically a reference to a list of permissions. This means more work for the developer and less flexibility for whoever manages the server permissions. This would make coding permissions for huge plugins a nightmare. Therefore, plugin developers would be less inclined to create parent nodes and it would be up to the server owners to create them themselves. In my opinion, this is a terrible design.
As for negation, nodes can be negated by setting them to false.
Users don't differ much at all between Permissions 3 and Bukkit Permissions.
On the user end, you will likely notice nothing if I set it up properly, but this just makes my job harder. Expect things to break sometime between now and 1.8 because I can't guarantee our current permissions plugin will hold until then.
