NAME
acps.conf — configuration file for the Access Control Policy Switch (ACPS)
DESCRIPTION
The ACPS configuration file controls which modules are consulted for
making an access control decision, the order in which the modules are consulted, and
the rules for combining their responses to return a result back to the
application.
Syntax and Default Behavior
The
acps.conf
file consists of one or more entries in the following format:
Label:ModuleName:Arguments:Flags
Whitespace in these entries is combined into a single blank (" ")
character and removed from the beginning and end of each field.
If multiple flags are specified, they should be separated with
a comma character.
The individual parameters are defined as follows:
- Label
The label provides a human-readable name for the module entry.
- ModuleName
The module name identifies the actual shared library to load to effect
the authorization decision.
The module name is specified without a path or a suffix (for example,
.sl),
both of which are assumed from the architecture.
- Arguments
The arguments are defined by the module (that is, module dependent) and are
used to provide additional configuration flexibility.
- Flags
The
Flags
field is used to modify the switch's behavior in interpreting
the results of the module.
See
Entry Flags
for more details and possible values for this
field.
The order of the entries in the acps.conf file denote the order in which the modules
should be called to perform the access check.
Each entry is called in turn until an "authoritative result code" is returned.
In the currently defined result code, everything except
ACPS_NOINFO
is authoritative.
Once an authoritative result code is returned by a decision
provider module, the code is returned
immediately to the application.
If
ACPS_NOINFO
is returned, the module is ignored and the next module is referenced.
ACPS_DENY
is returned to the application
if no module returns an authoritative result.
Entry Flags
In some cases, the default rules for ordering access requests and combining
results do not behave as expected for a particular decision provider module.
In this case, it is possible to affect the processing of the ACPS by
specifying one or more of the pre-defined
acps.conf
flags.
If you specify multiple flags, you should separate them
with a comma character.
There is currently
only one flag recognized by the switch.
The following flag may be
specified on a per-module basis:
- NONATTV
Short for 'non-authoritative', this flag is used for policy modules that always return
authoritative responses, even when they should not.
Specifically,
NONATTV
modifies the processing of the entry such that a
return of
ACPS_DENYistreatedas
ACPS_NOINFO.
The effect of this is that multiple modules may be stacked with
this flag, such that if any module returns
ACPS_ALLOW,
then the switch returns
ACPS_ALLOW.
EXAMPLES
The following is an example
/etc/acps.conf
configuration file.
Lines that begin with the
#
symbol are treated as comments, and therefore ignored.
# First, attempt to satisfy access request using custom
# module, (e.g. granting all users access to a particular
# object foo, but only between 9am - 5pm). The custom
# module verifies the time and that the object matches
# the specified argument. (In this case, "foo".) If this
# module returns ACPS_DENY, keep going to the next entry
# rather than just returning deny to the application.
HP-UX RBAC : libacpm_timebased : foo : NONATTV
# If custom rule does not match, use default local RBAC
# rule processing
HP-UX RBAC : libacpm_hpux_rbac : :
Printable version
