acps man page on HP-UX

Printed from

acps(3)								       acps(3)

       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‐
       vide access-control
		      decisions. A module can write to the SPI to  plug-in  to
		      the applications that call the API.  See acps_spi(3) for
		      more information.

       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‐
       sponding manpages.

   Access Request Fundamentals
       The ACPS framework recognizes three fundamental components of an access
       control request:

       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:

   Subject Types
       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,

   Credential Types
       Kerberos ticket encoded in ASN.1 DER.

       Cleartext password.

       Cleartext pin represented as a string.

       SAML credential assertion.

       Base64 ASCII encoded certificate.

   Subject Attributes
       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.

   Operation Types
       Literal encoded operation string.

       Hierarchically encoded operation string using "." as the separator.

   Object Types
       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.

   Environment Attributes
       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
	      de-allocating memory.

       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.

       acps_api(3), acps_spi(3), acps.conf(4), rbac(5).


List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net