man/man3nsl/rpc_gss_get_principal_name.3nsl

         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 "November 22, 2021"
 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.example.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.