xref: /illumos-gate/usr/src/man/man3nsl/rpc_gss_get_principal_name.3nsl (revision 2aeafac3612e19716bf8164f89c3c9196342979c)
te
Copyright (C) 2002, Sun Microsystems, Inc. All Rights Reserved
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
RPC_GSS_GET_PRINCIPAL_NAME 3NSL "Feb 25, 2017"
NAME
rpc_gss_get_principal_name - Get principal names at server
SYNOPSIS

#include <rpc/rpcsec_gss.h>

bool_t rpc_gss_get_principal_name(rpc_gss_principal_t *principal,
 char *mech, char *name, char *node, char *domain);
DESCRIPTION

Servers need to be able to operate on a client's principal name. Such a name is stored by the server as a rpc_gss_principal_t structure, an opaque byte string which can be used either directly in access control lists or as database indices which can be used to look up a UNIX credential. A server may, for example, need to compare a principal name it has received with the principal name of a known entity, and to do that, it must be able to generate rpc_gss_principal_t structures from known entities.

rpc_gss_get_principal_name() takes as input a security mechanism, a pointer to a rpc_gss_principal_t structure, and several parameters which uniquely identify an entity on a network: a user or service name, a node name, and a domain name. From these parameters it constructs a unique, mechanism-dependent principal name of the rpc_gss_principal_t structure type.

PARAMETERS

How many of the identifying parameters (name, node, and domain) are necessary to specify depends on the mechanism being used. For example, Kerberos V5 requires only a user name but can accept a node and domain name. An application can choose to set unneeded parameters to NULL.

Information on RPCSEC_GSS data types for parameters may be found on the rpcsec_gss(3NSL) man page. principal

An opaque, mechanism-dependent structure representing the client's principal name.

mech

An ASCII string representing the security mechanism in use. Valid strings may be found in the /etc/gss/mech file, or by using rpc_gss_get_mechanisms().

name

A UNIX login name (for example, 'gwashington') or service name, such as 'nfs'.

node

A node in a domain; typically, this would be a machine name (for example, 'valleyforge').

domain

A security domain; for example, a DNS or NIS domain name ('eng.company.com').

RETURN VALUES

rpc_gss_get_principal_name() returns TRUE if it is successful; otherwise, use rpc_gss_get_error() to get the error associated with the failure.

FILES
/etc/gss/mech

File containing valid security mechanisms

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE ATTRIBUTE VALUE
MT-Level MT-Safe
SEE ALSO

free(3C), rpc(3NSL), rpc_gss_get_mechanisms(3NSL), rpc_gss_set_svc_name(3NSL), rpcsec_gss(3NSL), mech(4), attributes(5)

ONC+ Developer's Guide

Linn, J. RFC 2078, Generic Security Service Application Program Interface, Version 2. Network Working Group. January 1997.