TMI-2 Mudlib Security and Permissions

1. Groups

	MudOS has a security system much like that of UNIX.  There are two
files which handle the permissions for the entire mud.  They are 
/adm/etc/groups and /adm/etc/access.  The "groups" file allows the mud to
set up groups in the mud which perform specific tasks and to give the group
a name.  For example, a mud might have the groups be its guilds or may
permit only those with proper knowledge access to crucial files.
Any single line in this file that is not blank or preceeded by a # defines
a group.  (The # lines are comments.)  The correct format follows:
 group name		user names
(root)			buddha:mobydick:wark

Note the delimiters in the line; the parentheses around the group name,
the colons between user names, and finally a carriage return at the 
end of the line.  When adding new groups, be sure to have the 
carriage return at the end of the line; if you do not put it in, problems
will occur.

You can also define groups recursively: that is, once you have defined
the (root) group above, you can then define this group:

(stuf!s)	(root):huthar:truilkan:jacques

and the substitution will be done properly.

You can find out whether a user is a member of a group using the member_group
simul_efun. It takes two arguments, both strings: the first is the user's
name (or object belonging to the user) and the second is the name of the
group. The member_group simul_efun will return 1 if the named person is
a member of the group, and 0 if not. This can be used to determine what
privileges a person has, by defining privileges for a group and then
adding and removing users from the groups accordingly. For example, most
of the powerful commands in /cmds/adm check to make sure that
the calling player is a member of the "admin" group before permitting the
command to execute.

2. Access to files

   The "access" file sets up access permissions for the groups defined 
in the groups file or for specific users.  This way only certain
groups can get into the directories they are allowed into. Wizards
are allowed access to his or her home directory automatically.
The proper format for each line follows:
directory		group and permissions
(/adm)			(root)[rw]:(wark)[r]:(all)[]

When permissions are defined, they apply to the directory in 
parentheses and any subdirectories not explicitly defined in the 
access file later. For example:

(/foo)		(all)[rw]
(/foo/bar)	(all)[r]
give all users read and write access to the foo directory and to all of
its subdirectories except the bar subdirectory, which they have only read
access to.

  Also, note there is no 'x' or executable flag on
the permissions, only read and write (r & w).  Finally, the (all)
group is not explicitly defined anywhere.  It is simply a group
implying all users on the mud.  In other words, anyone other than
the user, Wark, and the group, Root, have no permissions to use the
directory /adm in the above example.

When a user attempts to read or write to a file, one of two applies
in the master object is called. They are valid_write and valid_read,
the appropriate one being called. These functions call the lfun check_access
in the master object (defined in /adm/obj/master/access.c) which looks up
the user's EUID in the access file and determines whether or not to allow
access. Valid_read and valid_write can be used to perform other checks
as well. For example, this is where wizards get write access to their
home directories.

The only exception to this system is for files beginning with /d/, ie
files in mudlib domains. For these files, instead of querying the access
file, check_access passes control to the appropriate domain master object,
and allows that object to determine what level of access is permitted. This
allows domain lords to alter permissions within their domain without
having to give them permission to write ROOT_UID files anywhere in the
mudlib. See the domains file in this directory for more information.