The Muck Manual Admin Security

Bonisiwe Shabane

-Nov 18, 2025, 6:58 AM

Security problems are, fortunately, rather rare on MUCKs. Most MUCKs function — quite successfully — in a climate of trust, but giving thought to security issues is one of your responsibilities as an administrator. The issues are magnified if you become an administrator on a large MUCK, or if your MUCK attracts a sizeable player base. In this section, `security' is meant as `protection against unauthorized modification or destruction of the database itself, or of database objects'. This is somewhat different than the related issue of privacy. Privacy issues are discussed in Section 5.2.4.

Being able to log onto the server account the MUCK is run from is the trump card of all security concerns. With access to this account, someone bent on mischief or destruction can do anything: change God's password, alter logs, or destroy the database and all backups. Someone bent on safeguarding the MUCK can undo any damage: no matter what has gone wrong or been destroyed on the MUCK, the world can be restored to sane and healthy condition by restoring... So, control over and awareness of who has access to this account is the foremost security concern. If you own the machine the MUCK runs on, and are able and willing to do all site administration tasks, the issue is considerably simplified: don't give anyone else the password to the account. For most MUCKs, the situation is a bit more murky.

Often someone else owns the machine. Sometimes the site administrator is a wizard on the MUCK, but only marginally involved in its day-to-day affairs. Sometimes several staff members end up having access to the account: God has access because it is, after all, her world; the site admin has access because it is, after all, his computer; the... (For some things, you can enlist server-side help from staff members without giving them access to the account. For example, a separate account could be set up for the security wiz, and you could copy the log back ups to a directory in that account, rather than game/logs. A separate account can be set up for the wizard who does character creation, with char requests to be mailed there, or mail can be forwarded to her.)

Of the various matters you'll need to consider, selecting a site is in many ways the easiest. You need a 7 x 24 connection to the Internet and a stable IP address, for a machine running some version of UNIX, with permission to run a constant process. This may reduce the number of options to one or none. If it's one, the decision is made: go with the site you have. If it is none, and you're set on running a MUCK, your options are: If you are in the fortunate position of being able to choose sites, consider the following factors:

The ideal is to run the MUCK on a machine that you own: compiling the server will be considerably easier, and you'll be able to restart the MUCK quickly in the case of a... Console access is also a significant security consideration: see Section 5.1.4 Putting a MUCK online, creating a world that will attract players, and dealing with the minor and major crises that will inevitably crop up over time is an inherently demanding and time-consuming task. For most, though, it is a labor of love, and the burdens can be shared among staff members. Administering a MUCK involves both technical and non-technical issues. Both can be quite insistent and pressing during a MUCK's early, formative stages: there are innumerable technical details to attend to, and the small population creates an artificially incestuous atmosphere in which non-technical issues...

As the world develops and attracts players, things stabilize, but both issues will remain. On the technical side, problems of dbase management and backward compatibility will replace the tasks of getting everything working right. On the non-technical side, player relations and changing levels of commitment from staff members will come to the fore. Both sets of issues are discussed in this section of the Manual. Privacy on MUCKs is a charged issue, and making good decisions about how to handle privacy issues requires making mature judgments in the face of seemingly contradictory considerations. On the one hand, there is no guarentee of privacy in an online environment.

On the other hand, there is no excuse for administrators who abuse their position to pry into the online lives of players on their worlds. On the one hand, the subjective experience of VR as a `safe' environment often leads people to let down their emotional guard... to reveal intimate or painful details of their lives to others online. Administrators should take every precaution against violating the implied trusts that lead these players to make such revelations. On the other hand, people have organized illegal activities online, and the administrators of worlds where this has taken place have been embroiled in legal issues as a result. Administrators owe it to themselves and to other players on the MUCK to take reasonable precautions against such cases.

Doing a good job with privacy issues is primarily a matter of following an important list of DON'Ts: Religiously abiding by these "don'ts" in conjunction with keeping a log of commands issued by players is a reasonable compromise. Be aware that if you do log commands, and players on your world are investigated for illegal online activities (which includes using online worlds to organize illegal RL activities), your command logs may be... It is not absolutely necessary for your AUP to state that you log commands, but you will be on firmer ground if you do so: players will not be able to claim that they... The command for getting rid of players is @toad. The syntax is:

This turns the Player object for player1 into an object of type Thing, and transfers ownership of all objects owned by player1 to player2. If player2 is not supplied, all objects owned by player1 will be @chowned to the wizard issuing the @toad command. The Thing object will retain all properties that were set on the player. Occassionally you will need to toad players: sometimes for particularly grave violations of the AUP, more often because the player wants to leave the world or has simply stopped showing up and you want... As discussed in Section 5.1.4, Security Concerns , Wizards should examine the properties of objects they @chown. If you are @toading a large number of players, or @toading a player with a large number of objects, it's a very good idea to supply a non-wiz player for objects to be @chowned...

This is of course espcially important if the player is being @toaded as a disciplinary measure for security violations. Your MUCK is itself a large, complex set of records, and most information you would need to record is automatically recorded, either in log files or the database itself. There is, though, one record that most administrators find extremely useful that MUCK itself has no mechanism for: player's email addresses. Life will be much easier if you religiously follow a practice of recording email addresses each time you run @pcreate. This will let you notify players of things like downtime and address changes, and — if you follow a policy of not accepting character requests from anonymous email sites such as Hotmail, Rocketmail, Yahoo,... — gives you some chance of identifying alternate characters controlled by the same player.

You can store this online (on the player object, in a property such as @/email), but it is more valuable to keep the record offline, so that you can access it if the MUCK... which is a prime example of when you would need the players' email addresses. A flat text file works fine for this. One other kind of record keeping may prove useful. It is occasionally necessary to issue warnings to players about AUP infringements, and the like. In order for such warnings to be a useful administrative measure, other wizards need to know about warnings you have issued.

A common and workable practice is to use a program that stores administrative notes about such matters in a wizard-only propdir on player objects. With it, you can see if any other wizards have noted AUP problems with a player before you decide what an appropriate response to an incident is. (An example of such a program is provided here.) UNIX gurus and C buffs should have little difficulty compiling a MUCK. For the rest of us, it is a potentially frustrating experience. This section of the manual is addressed to the rest of us: sysadmins and C developers, you can use this time to go toggle in a new kernal from the front panel of a...

MUCK is not a shrink-wrapped, plug-and-play product. It is, rather, a large freeware application developed over a number of years by skilled coders who are willing to devote innumerable hours to making something for other people to use and enjoy. It is assumed that you — the site administrator — have reasonable facility with the UNIX operating system and a basic understanding of how to configure the program by editing C source code configuration... In other words, like UNIX itself, MUCK is quite user-friendly, but rather choosy about who its friends are. The following overview may help you get on speaking terms with your new server. It is of course madness to try to set up a MUCK without knowing UNIX.

Nonetheless, people often try, and often succeed. A good book on UNIX will be a worthwhile investment if you are going to be the MUCK's site administrator. If the set up goes smoothly — that is, if your system has everything where MUCK expects it to be — this information should be all you need. If you encounter compilation errors, you'll need to enlist help. Those sysadmins and C developers will be through toggling in their microkernals by the time you've gotten that far, and will no doubt be MUCK'ing somewhere. Go to a large MUCK, and try a public shout, or paging helpstaffers and wizards, asking if someone can lend a hand compiling a MUCK.

Getting your server up and running involves the following steps: There are a number of online resources for getting help with questions or problems. The server command help (syntax help <topic>) provides online documentation of many (but not all) server commands and features. Many (but not all) user-created commands follow the convention of including a #help function (syntax <command> #help). For example, you can get information on using the page program by typing page #help. MUF and MPI both have online documentation: for MUF, type man <topic>; for MPI, type mpi <topic>.

Additional information can be found in the news and info files. Typing either of these commands should show a list of topics. The news and info files are written and updated by a wizard; their content and quality will vary widely. The staff should also be able to provide help and information: type staff or helpstaff to get a list of available staff members. Smaller MUCKS may not have a separate helpstaff; in this case type wizzes. There was an error while loading.

Please reload this page. Permission: all programs in fbmuf.tar and the start-up database are in the public domain. For other programs, you should make a good faith effort to honor the conditions for porting programs. Read the program's header comment, looking for notes about permission and/or the author of the program. If the program says it can't be ported without permission, don't: instead, contact the program's author and ask for permission, or find a similar program that can be freely ported. Sometimes you just can't get in contact with the author, usually because he is no longer MUCK'ing.

The Muck Manual Admin Security

People Also Search

Security Problems Are, Fortunately, Rather Rare On MUCKs. Most MUCKs

Being Able To Log Onto The Server Account The MUCK

Often Someone Else Owns The Machine. Sometimes The Site Administrator

Of The Various Matters You'll Need To Consider, Selecting A

The Ideal Is To Run The MUCK On A Machine