Minecraft – Disabling Plugins for Users

minecraft-java-editionmods

I'm starting to run my first Minecraft server (using Bukkit latest on 1.7.4), and for the most part I just want it to be a base game. However, to protect a few things, I of course need a couple of plugins. (Particularly this is to use WorldGuard to protect specific areas that were complex to build. I can always restore from backup, but if a lot of time passes before I notice a problem then that's not really a win.)

While I can use WorldGuard to accomplish what I need, I would prefer if it's a base game for other players. Is there an easy way to accomplish this?

The closest thing I could find was this question, particularly the top two answers. The accepted answer looks good, but it seems to just disable the listing of plugins and not the actual interaction with them. A user could still simply try various commands and find the plugins. The next answer involves aliasing several things to the /help command, which also helps. However, I'd also have to build a custom /help response and alias all possible commands (plugins included) except the base commands, and I don't have those lists of commands. It also seems like a losing game, especially if an update changes/creates commands. Additionally, it looks like I'd be overriding the commands for myself as well, which isn't desired.

Is there any way to achieve what I'm trying to do? I just want WorldEdit/WorldGuard to be entirely unknown/inaccessible to other users so they just have a base game (and can petition me to "protect" areas they want to protect).

Or am I going about this all wrong? I've only ever played the base game, no mods, and have only ever played locally. So I'm very much in uncharted territory with mods. I guess I just want to make sure that I'm not opening up more than I should, since I don't have a complete picture of what these mods allow users to do.

Best Answer

Welcome to the wonderful world of CraftBukkit server administration. It can be a scary and frightening trip, but with some forethought and planning you will be able to control your player’s access levels to however you see fit.

The short answer is that you need a permissions plugin such as PermissionsBukkit, PEX, etc. that lets you tailor access levels for specific players, groups, or a combination thereof.

That said, there is a learning curve on how to set up permissions and staying current with plugin changes. Because this would be your first foray into permissions configuration, I recommend that you begin with PermissionsBukkit. This is not the place to give you a full permissions tutorial, but I will highlight some key points.

Almost all permission systems are based on the concept of users and groups to which individual permissions can be assigned that either allow or deny access to a plugin’s command or feature. In the case of PermissionsBukkit, permission configurations are maintained in config.yml, which will be located inside the plugins/PermissionBukkit directory after it is run for the first time. For example, if you want to prevent everyone but your trusted moderator steve from listing plugins, a simple configuration as follows will do.

users:
    steve:
        groups:
        - moderator

groups:
    default:
        permissions:
            bukkit.command.plugins: false

    moderator:
        permissions:
            bukkit.command.plugins: true
        inheritance:
        - default

Any player that is not specifically configured with permissions is assigned to the default permissions group. With that in mind, any player other than steve or you (I'm assuming you're set up as ops), will be assigned the permission bukkit.command.plugins with a value of false, which denies them from using the /plugins command. However, because steve is assigned to the group moderator he gets the same permission token but with a value of true allowing him to use the command.

I'll quickly touch upon the notion of inheritance. In the above configuration, the group moderator is set up to inherit permissions from default. Essentially, what this means is that group moderator will have the same permissions as group default adjusted accordingly by the permissions assigned directly to it. In this example, moderator inherits the false value, but then overrides it with a true value.

While this example doesn't achieve what you want to do, it does show you how to enable or disable a command, the concept of which can be extended to any plugin command or feature. Once you become accustomed to thinking in terms of permissions, configuration will become easier.

Obviously the next burning question is "What permissions I can set for a plugin?" Most plugin developers do a pretty good job of documenting permission configurations, but it wouldn't be the first time that developers release a new version and completely turn the commands and permissions upside down without leaving a hint or clue in the documentation. Fortunately, it doesn't happen too often and you will eventual learn which one of your plugin developers is such a culprit. Performing due diligence on a plugin is the only cure to avoid those problems with certainty during an upgrade.

There are several steps you can take to shield yourself from configuration nightmares and get as much information about a plugin's commands and permissions:

  • Your first line of defense is to devour a plugin's documentation. Most developers provide configuration information that explains what commands and features you can control on BukkitDev.
  • Your second line of defense is to open the plugin JAR file with WinZip, WinRAR, or similar compression software. JAR files are just a special version of ZIP files. Therein you will see a plugin.yml file which you can open up with any text editor (e.g. NotePad++, vi, etc.). Any plugin developer worth his or her salt will document plugin commands and permissions within this file.
  • Your last line of defense is to review a plugin's source code. Most plugins, will have links to a source code repository (e.g. GitHub, BitBucket, etc.) that let you browse through Java code and get an idea of what permissions do what.

If you aren't a programmer, source code will probably be cryptic and not serve you well in gleaning additional information; but, you never know, it might peak a new interest. Our server has a strict policy for only using plugins with published source code. This policy ensures that we can assess the quality of programming and that we can maintain it ourselves should its developer disappear (happens quite often). Above all, avoid plugins whose descriptions start off with I'm new to Java, but I made this plugin... This is my first plugin... This works great on my private server... You get the point.

Don't bother looking at the plugin.yml file for WorldGuard. Its a great plugin (though we use Residence), but its developer sk89q who also authors WorldEdit insists on doing permissions his own way - the details of which make an interesting read. You will have to solely rely on his documentation (wiki.sk89q.com/wiki/WorldGuard) since there is no additional information in bukkit.yml

Alright, I will stop here before I start discussing the finer points and intricacies of plugin administration and configuration. I hope that this will point you in the right direction. Best wishes to your venture.