Who Does What?

The DCE Security Service ACL API consists of the following routines:

· sec_acl_bind( )

· sec_acl_bind_to_addr( )

· sec_acl_calc_mask( )

· sec_acl_get_access( )

· sec_acl_get_error_info( )

· sec_acl_get_manager_types( )

· sec_acl_get_mgr_types_semantics( )

· sec_acl_get_printstring( )

· sec_acl_lookup( )

· sec_acl_replace( )

· sec_acl_test_access( )

· sec_acl_test_access_on_behalf( )

As their names suggest (full descriptions can be found in the OSF DCE Application Development Reference), these routines are what DCE clients call to use and manipulate ACLs, namely: bind to an object's ACL; retrieve an ACL; replace (that is, write to) an ACL; test (via its ACL) access to an object, and so on.

A properly-set-up DCE application does not have to implement any of these operations; they are all taken care of by the remote ACL implementations in the DCE ACL library. The only exception to this statement involves the binding operation. The application must register a routine that can be called by the ACL library whenever necessary to make up a complete binding to a specific ACL (this involves returning an ACL UUID, as will be seen below). This is the application's hook into the ACL library implementations: the registered routine will always be called during a binding operation on any of the application's ACLs, and once it has given the library a binding to the desired ACL, the library routines can perform any requested operation with it.

The application is thus not responsible for implementing any ACL interface operations. What the application is responsible for is the following:

· Setting up the necessary ACL data types and descriptions.

· Supplying a routine that resolves object names into ACL UUIDs.

· Setting up persistent databases in which the ACLs can be stored and retrieved.

· Initializing the ACLs for all existing objects.

The purpose of the following topics is to describe how these requirements can be fulfilled.