 # Mudlib Documentation
 
   File    : /adm/obj/master/valid.c
   Brief   : Contains valid hooks
   Date    : 21-DEC-05
   Updated : 21-DEC-05
 
 INTRODUCTION:
 
valid.c is an extreamly important part of the mudlib
and contains all hooks (applies) that MudOS will call
in the master object that have to do with security
(valid_*). This object also parses the access
and group files (which are defined by a preproccessor
define at the top of the file) and contains several
other functions that relate to security. It is important
to note that valid.c only contains security functionality
that is requires interaction with the driver (or disregard
to security). All other security related functionality
should be placed in a different daemon in /adm/daemons
(ie. security_d.c)

  OPTIONS:

This file has three preproccessor definitions that you
can modify; DEBUG, FILE_ACCESSDATA, and FILE_GROUPDATA

By defining DEBUG, it will write helpful information to
/log/security

FILE_ACCESSDATA and FILE_GROUPDATA must be defined or the
mud will not boot succesfuly. These defines point to
their respective file (ie. FILE_GROUPDATA points to
'/adm/etc/groups' by default)

  FUNCTIONALITY:
  
To query membership of a individual for a specific group:

 There is a simul_efun called isMember that your code can
 make use of (instead of making a length statement to call
 the master object it's self). Both arguments to this
 function (and simul_efun) are strings; the first is the
 individual's username and second is the group's name.
 
To get all user's of a group:

 To get an string array of all the different users in a group,
 you must call 'query_group' with the group name as the argument.
 The function returns a string array, each element contains
 a member's name.
 
Other:

 Besides the the two above, you most likely will not need
 this object for anything else. If you want to make smart
 errors for your lpc objects (instead of getting a nasty
 lookg error), you can call valid_* (with * being replaced
 with the apply) to check permission. Refer to the source
 code for the arguments to the differnt valid applies.
 
 An example of use is below:
 
 if(!master()->valid_write(str, this_player(), "rmdir"))
        return(notify_fail("Error [rmdir]: Permission denied.\n"));

  INTERNALS:
 
  You may want to note the following:
  
   - this_object() or master() will always return 1
   
   - For valid_read and valid_write, it uses the priv
          of this_player() unless the object passed
          as the argument has a priv of [daemon] or if
          the file is in a home directory.
    
   - If it can't find the priv of an object, it will default
          to noname.
          
   - valid_read and valid_write will always return 1 for
          user's data file.
          
   - Object in a user's home directory can write to
          that home directory. It is important to note
          that objects in a home directory have a priv of
          '[home_<user>]' with <user> being replace with the
          user's name (as defiend by home directory). 
     
   - valid_read and valid_write will always return 1 for
          the directory 'public' under a user's home directory.
          
   - valid_read and valid_write will only let a user (and admin)
          read and write to the directory 'private' under a
          user's home driectory.
          
   - If there is no permissions set for a directory. IT will work
          it's way up through parent directories intill it can find
          permissions.
          
   - If a user does not have permissions to a directory, the user
          will recieve the permission of the group 'all' (if defined).
          This means you can access permissions to the pseduo group
          'all' and everyone else that isn't explictly designated
          permissions for that directory will fall back to 'all'.
          
   - If a user is not explictly assigned permissions to a directory,
          valid.c will search through all the groups that have been
          assigned permissions to see if that user is a member of
          any of those groups. If a user is a member of oen of those
          groups, it will inherit the permissions of the first group
          encountered in it's search.
          
   - valid_save_binary will only return 1 (adn will always do so)
          if the object is under the '/adm' directory.
          
   - valid_override will always allow the simul_efun override
          it's override but will not allow any other object
          to override a simul-efun to use the actual efun.
          The only exception to the rule is the object
          inheritable which may call destruct. You may
          add more exceptions if required.
          
   - valid_object will be called when an object is created.
          Not everytime a user calls an object.
          
   - valid_link will return 1 if the previous_object has
          permissions to link in both directories.
          
   - valid_compile_to_c will always return 0
   
   - valid_shadow will return 1 if the object being
          shadowed has permission to be shadowed.
          
                                                                                                           
 
  
 
 
 
   
  
    