Specifications

Remote Procedure Call Programming Guide Page 21
4.4. Authentication
In the examples presented so far, the caller never identified itself to the server, and the server never required
an ID from the caller. Clearly, some network services, such as a network filesystem, require stronger secu-
rity than what has been presented so far.
In reality, every RPC call is authenticated by the RPC package on the server, and similarly, the RPC client
package generates and sends authentication parameters. Just as different transports (TCP/IP or UDP/IP)
can be used when creating RPC clients and servers, different forms of authentication can be associated with
RPC clients; the default authentication type used as a default is type none.
The authentication subsystem of the RPC package is open ended. That is, numerous types of authentication
are easy to support.
4.4.1. UNIX Authentication
The Client Side
When a caller creates a new RPC client handle as in:
clnt = clntudp_create(address, prognum, versnum,
wait, sockp)
the appropriate transport instance defaults the associate authentication handle to be
clnt->cl_auth = authnone_create();
The RPC client can choose to use UNIX style authentication by setting clnt−>cl_auth after creating the
RPC client handle:
clnt->cl_auth = authunix_create_default();
This causes each RPC call associated with clnt to carry with it the following authentication credentials
structure:
/*
* UNIX style credentials.
*/
struct authunix_parms {
u_long aup_time; /* credentials creation time */
char *aup_machname; /* host name where client is */
int aup_uid; /* client’s UNIX effective uid */
int aup_gid; /* client’s current group id */
u_int aup_len; /* element length of aup_gids */
int *aup_gids; /* array of groups user is in */
};
These fields are set by authunix_create_default() by invoking the appropriate system calls. Since the RPC
user created this new style of authentication, the user is responsible for destroying it with:
auth_destroy(clnt->cl_auth);
This should be done in all cases, to conserve memory.
The Server Side
Service implementors have a harder time dealing with authentication issues since the RPC package passes
the service dispatch routine a request that has an arbitrary authentication style associated with it. Consider
the fields of a request handle passed to a service dispatch routine: