Index for Section 4

Alphabetical listing for E

Bottom of page

evm.auth(4)
NAME
  evm.auth - EVM authorization file

SYNOPSIS
  event_rights	  {
	  class	 event_class
	  post	 rights_list
	  access rights_list
	  }

  service_rights  {
	  service service_name
	  execute rights_list
	  }

DESCRIPTION
  Authorization is control of the right to post, subscribe to, or retrieve an
  EVM event, or to execute services defined in the EVM daemon configuration
  file.

  The evm.auth file is a text file that controls event authorization. Any
  portion of a line from an unquoted number sign (#) to the end of line is a
  comment. Blank lines are ignored. The following authorization controls are
  recognized:

  event_rights
      The rights specified apply to event posting and subscription.

  class event_class
      Class of events to which these rights apply. An event_class is a string
      of one or more components that match the same set of components in an
      Event Name. It is used to identify a family of events for purposes such
      as authorization. The more specific classes (those with more
      components) override the rights indicated by the less specific (more
      generic) classes.

  post rights_list
      Users specified by the rights_list are allowed or denied the right to
      post events of this event_class.

  access rights_list
      Users specified by the rights_list are allowed or denied the right to
      subscribe to or retrieve from the log, events of this event_class.

  rights_list
      A list of users or groups who have or are denied the specified right
      for this event or service class. Entries are separated by commas.

      A rights_list has the format:

      [+|-][user | group=groupname]

      In the previous rights_list, user is the login name of any user, and
      groupname is any group. The keyword group may be abbreviated to grp. A
      leading plus character (+) signifies that event or service rights are
      granted. A leading minus character (-) signifies that rights are
      explicitly denied. User root has implicit posting and access rights to
      all events, and execute rights to all services, unless they are
      explicitly denied.

      The first explicit entry for a user in a rights list takes precedence
      over any other explicit or group entries for that user. If the user is
      not explicitly listed, but is a member of a group which denies access,
      access is denied even if the user is also a member of a group for which
      access is granted.

      A plus or minus sign with no associated name grants or denies rights to
      all users.

      The rights_list must be enclosed in double quotes if it contains
      spaces.

  service_rights
      The rights specified apply to services performed by the daemon for a
      requesting client.

  service service_name
      The service to which these rights apply. The service_name is the name
      of a service defined in the evmdaemon.conf file. User-defined services
      are not currently supported.

  execute rights_list
      Users specified by the rights_list are allowed or denied the right to
      request operation of this service.

  The keywords described may be entered in a case-insensitive manner.  The
  allowable strings and the minimum number of characters is shown in the
  following table. A minimum of zero (0) indicates that all characters are
  required.

  ________________________
  Keyword	   Minimum
  ________________________
  access	   0
  class		   0
  event_rights	   7
  execute	   4
  post		   0
  service	   4
  service_rights   9
  ________________________

NOTES
   1.  If you add an event_rights entry to the authorization file, you must
       make sure there is a corresponding base event template in the template
       file library. The base template must have a name whose components
       exactly match the corresponding components in the authorization file's
       class value. The template name can have fewer components than are
       present in the class, but it cannot have more.  For example, if an
       event_rights group has a class value of myco.myprod.payroll, and an
       event template with the name myco.myprod has been registered in an EVM
       template file, the template will be regarded as the base template for
       the class.

       Each time the daemon loads or reloads its configuration, it writes a
       warning message in its error file if no base template is registered
       for a particular event_rights entry. Refer to the evmtemplate(4)
       reference page for information about registering event templates.

   2.  If you are concerned with allowing your file to be used on other
       systems that support EVM in the future, you should use the built-in
       macro @SYS_VP@ in place of the first two components (sys.unix) of the
       name of any system event. This will make it unnecessary to change the
       file if the other system uses a different event name prefix.

EXAMPLES
  This example illustrates an entry in the authorization file with the
  following privileges:

   1.  Only root may post events that have myco.myapp as the first two
       components of the event name.

   2.  Events in this class may be accessed by root or by any user who is a
       member of the tech group.

       event_rights    {
			class	     myco.myapp
			post	     +root
			access	     "+root, +group=tech"
		       }

FILES
  /etc/evm.auth
      Location of the EVM authorization file.

SEE ALSO
  Commands: evmd(8)

  Files: evmdaemon.conf(4), evmtemplate(4)

  Event Management: EVM(5)

Index for Section 4

Alphabetical listing for E

Top of page