ACPS - Access Control Policy Switch
[flag]... file... [library]...
The Access Control Policy Switch (ACPS) provides a layer of separation
between applications that must make authorization decisions and the
underlying modules that provide a decision response by interpreting
some form of pre-configured policy. The switch provides three inter‐
An Application Programming Interface that access-control-aware applica‐
can call to request an authorization decision. See
acps_api(3) for more information.
A Service Provider Interface (SPI) that allows custom modules to pro‐
decisions. A module can write to the SPI to plug-in to
the applications that call the API. See acps_spi(3) for
A configuration interface (file configuration) that administrators use
deployment time to select the module (or set of modules)
referenced to make authorization decisions. See
acps.conf(4) for more information.
Each of these interfaces is described in greater detail in their corre‐
Access Request Fundamentals
The ACPS framework recognizes three fundamental components of an access
Subject The entity attempting to access the resource. In the
context of an operating system, the subject is commonly
a user or a process associated with a user.
Operation An action performed on a resource. An operation can cor‐
respond directly to an application or command. In the
case of HP-UX RBAC, the operation is a dot-separated,
hierarchical string such as
Object The target of the operation. This is often the same as
the end resource.
In addition to these core components, there are sometimes additional
attributes of the subject, operation, object, or environment that
affect the access control decision. The ACPS framework is designed to
allow the application to specify additional attributes as appropriate,
and convey this information to the modules configured to reply to the
The final piece of information passed through the ACPS is a form of
proof that the subject is actually who he or she claims to be. This
proof, called a credential, can be in several different forms, for
example a password or a Kerberos ticket. Depending on the decision
provider and its established trust relationship with the application, a
credential might be optional.
The ACPS framework is designed to allow the application to pass various
attributes to the decision provider. To facilitate a common under‐
standing of the possible types of attributes and components, the ACPS
framework requires most parameters to carry an associated type that
might be implicitly or explicitly specified.
These types are common to both the application interface (API) and the
decision provider interface (SPI) and are defined as follows:
HP-UX username associated with the subject.
RFC822 identifier of the subject (for example,
HP-UX UID associated with the subject encoded as a
X.500 identifier of the subject (that is,
Kerberos ticket encoded in ASN.1 DER.
Cleartext pin represented as a string.
SAML credential assertion.
Base64 ASCII encoded certificate.
Comma-delineated list of (active) roles associated with the subject.
The GECOS information associated with the subject, as defined in the
passwd file or other Name Services Switch repository.
Comma-delineated list of groups associated with the subject.
The shell associated with the subject, as defined in the passwd file
or other NSS repository.
Literal encoded operation string.
Hierarchically encoded operation string using "." as the separator.
CIM version 2.8 object representation encoded in XML.
File object encoded as a path.
Object encoded as a generic string with no additional interpretation.
Object encoded in uri syntax.
Compartment tag associated with the access control request. The inter‐
pretation of "associated" is left to the application.
The requested access was granted. This return code is only returned as
a result of requests.
The ACPS is configured incorrectly.
This might be the result of a syntactic error in the file.
The requested access was not granted.
This return code is only returned as a result of requests.
The requested operation failed.
This is the default error code for any operation when a more
specific error code does not apply. When this is returned as
the result of a call , the application should not allow access
to the specified resource.
The requested operation failed as a result of an error allocating or
The requested access was denied as the result of the lack of a
necessary credential. After the requested credential is sup‐
plied, the application can call again, which might result in an
allow. If the application cannot supply the necessary creden‐
tial, it should treat this result as equivalent to an
The repository has no access control information on the user.
This return code is only returned as a result of requests and is
never returned to an application.
The requested operation was successful.
This is never returned as the result of a request.
SEE ALSOacps_api(3), acps_spi(3), acps.conf(4), rbac(5).