evm.auth(4)evm.auth(4)NAMEevm.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 con‐
trols are recognized: The rights specified apply to event posting and
subscription. 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. Users specified by the rights_list
are allowed or denied the right to post events of this event_class.
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. 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 (-) signi‐
fies 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. The rights specified apply to services performed by the
daemon for a requesting client. 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 cur‐
rently supported. Users specified by the rights_list are
allowed or denied the right to request operation of this ser‐
vice.
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 charac‐
ters are required.
─────────────────────────
Keyword Minimum
─────────────────────────
access 0
class 0
event_rights 7
execute 4
post 0
service 4
service_rights 9
─────────────────────────
NOTES
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. 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: Only root may post events that have myco.myapp as
the first two components of the event name. 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
Location of the EVM authorization file.
SEE ALSO
Commands: evmd(8)
Files: evmdaemon.conf(4), evmtemplate(4)
Event Management: EVM(5)evm.auth(4)