Everything you ever wanted to know about access.cnf

The file "access.cnf" in the game/ subdirectory controls access to the MUSH. It's used to restrict which sites can conect to players or guests, create players, or register players by email. It can also flag a site as suspect; all players who connect from suspect sites have their SUSPECT flag set.

This file replaces the older lockout.cnf and sites.cnf file; typing 'make access' will create a new access.cnf file from your lockout.cnf and sites.cnf files.

File syntax

The syntax of the file is simple. Each line gives information about a host or host-pattern:

[user@]host [options] [# comment]

• host - the only required entry, this is a hostname or a wildcard pattern to match. Examples:

  
           berkeley.edu	- matches hostname berkeley.edu
  	 *.berkeley.edu - matches hostname <anystring>.berkeley.edu
           *berkeley.edu  - matches either of the above
           *              - matches all hosts
  
  

• user@ - if the host supports ident, and you trust the ident response, and you're sure that the link is fast enough that you'll always get an ident response in time, you can match for specific users. Example:

  
  johnq@netcom.com
  
  

• options - A space-separated list of options which apply to connections from the host. Described in detail below.
• comment - an optional comment

Everything in the file is separate by a single space - don't use tabs.

The file is read line-by-line, and the first match is used. This means that the order in which hosts are listed is very important.

There is one special line in the file, which looks like this:

@sitelock

This line indicates where @sitelock'd sites will be inserted in the file. Hosts listed after this line can have their access options superseded by using @sitelock on-line. Hosts listed before this line can not have their access options overriden by @sitelock.

If the line doesn't appear in the file, it will be added to the end of the file at startup.

Reading and writing the file

The access.cnf file is read and cached at startup, and whenever the MUSH receives a HUP signal.

The access.cnf file is written back to disk whenever @sitelock is used.

Options

The following options are available for each host in the file:

If no options are given, the host is treated as if option "none" were used. If at least one option is listed, it's assumed that hosts can do anything (create, connect, guest) that they are not prohibited from.

Example scenarios

Here are some typical ways you might want to set up your file:

1. Totally ban specific sites, allow all others

   
   *badsite.com none
   *.twink.edu none
   
   

   This will totally lock out those sites (like lockout.cnf)

2. Allow specific sites and no others

   
   *.berkeley.edu default
   * none
   
   

   People may connect from .berkeley.edu sites only.

3. Allow connection but not creation from some sites

   
   *.twink.edu !create
   
   

   This is equivalent to the former function of sites.cnf

4. Allow connection but not creation or guest-connection from some sites

   
   *.twink.edu !guest !create
   
   

5. Require that a given site use the 'register' command to register players by email.

   
   *.twink.edu !create register
   
   

   Using !create prevents people from using the usual create command.

   Adding register allows them to uset the register command.

6. Disable creation from twink.edu sites, and don't let Wizards override this rule with @sitelock

   
   *.twink.edu !create
   @sitelock
   
   

   Because the rule appears above "@sitelock", and @sitelock rules appear below "@sitelock", the rule will always be checked before any @sitelock rules.

7. Disable creation from twink.edu sites, but allow Wizards to later override this rule with @sitelock

   
   @sitelock
   
   *.twink.edu !create
   

   Because the rule appears below "@sitelock", new @sitelock rules (which will be added immediately following "@sitelock") will precede it, and will be checked first.

8. A complex example:
   1. Allow anybody from localhost.berkeley.edu complete access
   2. Force people from *.twink.edu to use registration, and set their players SUSPECT
   3. Completely ban *badsite.com
   4. Don't allow jerk@netcom.com to connect to Guests
   5. Only allow people from somesite.org to connect to Guests.
   6. Allow @sitelock to override c-e above

   
   localhost.berkeley.edu default
   *.twink.edu !create register suspect
   @sitelock
   *badsite.com none
   jerk@netcom.com !guest
   somesite.org !connect !create guest
   
   

Comments to Gammon Software support