Bukkit

A MySQL based player control that implements the concept of superuser, borrowed from Unix. Players are managed using a MySQL table. SuperUser requires both Logblock and Pex for a full implementation.

OPs as Players

SuperUser complements the typical permission-by-plugin security found on most servers very nicely with its automatic player handling and damage rollback capabilities.

PEX permissions.yml

This plugin doesn’t just hook into the robust PEX permission system, it uses the PEX api to manage the permission groups. It uses PEX to configure itself, by group.

By-Player vs. By-Plugin

While SuperUser may appear to be an added level of complexity to Bukkit security, it also has the potential of simplifying admin or moderator duties. It allows admins to standardize, and control what players are allowed to do in terms of Minecraft features, by player. For example, Creative servers often experiment with new plugins and I bet they wish they could safely let players be ops so they can try the plugins out. Maintaining a constantly changing permission system can be a bear.

Since SuperUser doesn't concern itself with the use of specific plugins it is in a good position to catch outlaw players that have found backdoor access. SU catches them and deals with them. SU can be an unsettling surprise for players getting complacent with their server cheats.

Super User

Superusers, from now on called supers, are the only players not monitored. Players may have specific permissions, by player, that override any existing permission system. For example, a player may be an op, but that does not mean he/she can fly, use tnt, ban, change gamemode, etc.. unless this plugin permits it. A super could op a player asking to be op'd and strip that player of all Minecraft capabilities at the same time.

Supers are defined as such on the SQL player record. I would never claim the system is undefeatable because that would just tempt fate. But SQL servers are routinely trusted to handle financial transactions, and are designed to be secured. That portion of security is in the server builder's hands, and the tool is mature and solid.

Bukkit Versioning

SuperUser does not go outside th Bukkit api. Therefore, it will not break every time Bukkit renames Minecraft classes.

Asynchronous MySQL

Care is taken to run MySQL processing off the Bukkit/Minecraft thread. Theoretically, this plugin can have very little impact on general server performance, while doing a lot in terms of automatically managing players. Of course, the SQL server is often run on a separate machine, further relieving the Bukkit server of overhead. This is often called scaleability. The bulk of SQL referencing is by record id, the primary table index. This is the most effecient way to access SQL records, and requires no searching. This is like referencing an array value by index, instead of searching the arrray. It also happens to be blinking fast, requiring very little work.

Player Cache

This plugin employs a detailed player cache making it possible to service its listeners very quickly without the need to wait for SQL requests. This is done asynchronously whenever possible. Players are always cached while online, and flushed on quit. The player cached is periodically flushed to the table in the background, off the main thread. It may also be flushed on command, using the 'dirty' field. SuperUser was designed to be managed by a web app as well as console, and player.

Offenses

There are different categories of offenses such as felony, breach, trespass, harm, damage, etc... that are tallied when incurred. Offending players are clearly warned after an offense and reminded of how many warnings received. When a defined threshold of warnings is reached for a particular offence the player is moved to what is called the guest area, stripped of all permissions, and tarpitted. Guest players are not allowed to go beyond a defined radius from a defined location. Guests don't have editing privileges, nor chat access. Guests have only one command, and that is '/ask'. This is a line of communication only to supers, and must have a 10 second delay between uses. Guest'ing a player, for all practical purposes, is as good as banning a player, but without all the negative implications.

System kicked, or guest'ed players are reset and given another chance after 24 hours, unless banned.

Jail

SuperUser jail is defined by location and radius like the guest area but in effect works the opposite. Instead of containing players, it is designed to eventually let them out, hopefully rehabilitated. The /va_setjail command is used to define the jail location; the radius is set in ‘config.yml’. A player may be sent to jail from the console or as a super privileged player using ‘/jail <player> [minutes/default:10]’. The intrinsic jail command name is /va_jail, but SU responds to /jail and should override any plugin using the same command name, as well as penalize any non-super trying to use the command.

A jailed player retains his/her rank, but is relocated to jail and put and kept in survival mode until release. Jail birds, like guests, have only one command, and that is the time delayed '/ask'. It communicates only with supers. Release occurs when the term expires as defined from command, or when the jailed player leaves (escapes) the defined jail radius. A jailed player may still get system kicked if warnings are not heeded. It is assumed that a player is jailed for a reason that may involve griefing, so any work done since login is automatically rolled back upon incarceration, and again upon release or quit to restore the jail area.

Registration

SuperUser does use a non-invasive registration and login process designed to slow down hackers and provide a moderate level of security to an off-line server. Players only need to /register once, and /login only when their ip address has changed.

Commands

This Command List is directly from 'plugin.yml' and document the available commands. Player control may be done directly in the sql table. Use 'f' or '0' or 'n' for false and 't or '1', or 'y' for true. Use partial group names. Change the 'dirty' field to anything but 'false' and SuperUser will validate and implement the changes if it is for a live player. Type 'flush' in the dirty field to signal SuperUser to flush it's player cache out to database. This is designed for a user interface such as a web interface.

Command Confirm

The command confirmation I refined on my Postal plugin is employed on this plugin. This means that you only need to type enough characters of a player's name to uniquely indicate the name, and SuperUser will complete it for you. You will be given a chance to confirm it with a single'/'. SuperUser will try to uniquely complete on live players first before digging into the off-line players, unless it is a live player only command.

Stealth

The super field takes a true or false as expected, and also will accept 'stealth'. 'stealth' indicates not only super user status, but complete invisibility as well. Stealth supers do not register in the tabbed player list, nor are they announce at join, quit or death. They are not there, you see.... (actually, if you don't 'see', even better)

Player Tracker

Complementing the stealth capabilities is a powerful player tracker available only to supers. It uses the compass and a HUD reporter driven by the new Scoreboard api. Backwards compatibility is maintained by conventional messaging if the Scoreboard class is not detected. Super gets a compass needle maintaining a lock on the moving subject. The HUD reporter maintains distance and elevation statistics. There is no problem finding players with this tool. It is also good for teamwork. Two or more supers working together can maintain locks on each other so they always know exactly where each other is.

Rollback

Logblock is used to automatically rollback changes made by a player that ended up being kicked by the system or a super. Logblock also implements player settings that define whether their work is saved. For example, if a player's 'save_wrk' setting is 'false' Logblock will rollback the player's work since login when the player quits. Logblock is also used to maintain the defined jail and guest areas.

Getting Started

1) Put va_superuser.jar into your plugin folder and start the server, then stop it.

2) Edit 'config.yml' in the va_superuser directory to configure MySQL. The settings are straight forward for a normal MySQL instalation, and beyond the scope of this step description.

CONFIG.YML

3) Re-start the server and enter 'va_update' at the console to populate the player table with all the players on the server. Or, have the player to be super join and quit to create just that record.

4) Use the 'rank' command from the console to make that player a super using the PEX group used for admins:

rank <player> <group> super

5) Join the game as this super and register. Go to a location where you would like new users to spawn and enter '/va_setguest'. This area is used to cool off misbehaving players as well as, used for a pre-login processing. The radius is defined in 'config.yml' and may only be edited by a super.

THE SQL TABLE, DOCUMENTED

Comments