• Home
  • History
  • Annotate
  • current directory
Name Date Size #Lines LOC






MakefileH A D14-Feb-20211.7 KiB7429

Makefile.comH A D14-Feb-20217.4 KiB241146

README.spiH A D14-Feb-20214.7 KiB11382


THIRDPARTYLICENSE.descripH A D14-Feb-202138 21

g_accept_sec_context.cH A D14-Feb-20219.6 KiB393269

g_acquire_cred.cH A D14-Feb-202113.8 KiB550397

g_acquire_cred_with_pw.cH A D17-Apr-202311.4 KiB436310

g_buffer_set.cH A D14-Feb-20212 KiB6328

g_canon_name.cH A D14-Feb-20215.4 KiB207119

g_compare_name.cH A D14-Feb-20216.1 KiB214117

g_context_time.cH A D14-Feb-20212 KiB8137

g_delete_sec_context.cH A D14-Feb-20212.5 KiB10754

g_dsp_name.cH A D14-Feb-20213.6 KiB13980

g_dsp_status.cH A D23-Aug-202310 KiB414290

g_dup_name.cH A D14-Feb-20214.1 KiB15590

g_exp_sec_context.cH A D14-Feb-20213.5 KiB14085

g_export_name.cH A D14-Feb-20212 KiB7731

g_glue.cH A D23-Aug-202318.8 KiB714448

g_imp_name.cH A D14-Feb-202110.5 KiB369193

g_imp_sec_context.cH A D14-Feb-20213.9 KiB165103

g_init_sec_context.cH A D14-Feb-20216 KiB232141

g_initialize.cH A D14-Feb-202123.1 KiB939517

g_inq_context_oid.cH A D14-Feb-20212.5 KiB7932

g_inquire_context.cH A D14-Feb-20213.6 KiB15292

g_inquire_cred.cH A D14-Feb-20217.2 KiB283175

g_inquire_names.cH A D14-Feb-20214.4 KiB192124

g_oid_ops.cH A D14-Feb-20212.8 KiB10158

g_process_context.cH A D14-Feb-20212.1 KiB8539

g_rel_buffer.cH A D17-Apr-20231.4 KiB5921

g_rel_cred.cH A D14-Feb-20212.6 KiB10352

g_rel_name.cH A D17-Apr-20232 KiB8234

g_rel_oid_set.cH A D17-Apr-20231.5 KiB6527

g_seal.cH A D14-Feb-20214.6 KiB202129

g_sign.cH A D14-Feb-20212.9 KiB13578

g_store_cred.cH A D14-Feb-20215.4 KiB209131

g_unseal.cH A D14-Feb-20212.9 KiB12272

g_userok.cH A D17-Apr-20233.1 KiB13284

g_utils.cH A D17-Apr-20236.7 KiB300214

g_verify.cH A D14-Feb-20212.5 KiB10660

gssd_pname_to_uid.cH A D14-Feb-202113.3 KiB553371

inc.flgH A D14-Feb-20211 KiB312

mapfile-versH A D10-Dec-20214.3 KiB202194

oid_ops.cH A D14-Feb-202113.1 KiB535375

req.flgH A D14-Feb-20211.1 KiB323


4 The contents of this file are subject to the terms of the
5 Common Development and Distribution License (the "License").
6 You may not use this file except in compliance with the License.
8 You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
9 or http://www.opensolaris.org/os/licensing.
10 See the License for the specific language governing permissions
11 and limitations under the License.
13 When distributing Covered Code, include this CDDL HEADER in each
14 file and include the License file at usr/src/OPENSOLARIS.LICENSE.
15 If applicable, add the following below this CDDL HEADER, with the
16 fields enclosed by brackets "[]" replaced with your own identifying
17 information: Portions Copyright [yyyy] [name of copyright owner]
21 Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
22 Use is subject to license terms.
25	The Service Provider Interface for libgss and its Mechanisms
26	------------------------------------------------------------
281.  The libgss SPI upto 11/2004
30    Prior to PSARC 2004/810 the libgss SPI consisted of a function
31    provided by each mechanism whose return value is a pointer to a
32    structure full of references to the mechanism's entry points
33    (hereinafter: methods).
35    This structure does not include any hooks for versioning, which
36    means that additions of any mechanism methods at micro/patch
37    releases require patching libgss.so.1 and all the GSS mechanisms
38    shipped with Solaris (Kerberos V, DH, SPNEGO).
402.  The libgss SPI after PSARC 2004/810
42    In order to avoid changing the gss_config struct and patching all
43    three mechanisms (four, if the dummy mech counts) and libgss
44    together and in anticipation of a cleaner SPI in the future (see
45    next section) the SPI after PSARC 2004/810 will be as before but
46    supplemented as follows:
48     - any new SPI mechanism methods will NOT be placed in gss_config,
49       instead there is a new gss_config_ext structure, which is to be
50       used _only_ by libgss (to avoid struct versioning and/or patch
51       issues), which should be extended to have a pointer to the new
52       method;
54     - there is a new libgss function, __gss_get_mechanism_ext(), which
55       is used to get at the gss_config_ext for a mechanism;
57     - __gss_get_mechanism_ext() uses dlsym() to build the
58       gss_config_ext struct for the mech by individually loading each
59       and every mechanism method that isn't part of the old gss_config
60       struct -- this happens only once per-method, of course; the
61       result is cached.
63       The symbol names that are dlsym()ed are of the form gssspi_* and
64       correspond to gss_*; e.g., gssspi_acquire_cred_with_password().
66       New methods also have a corresponding typedef named
67       <gss_func>_sfct -- the 's' in 'sfct' is for "SPI" and the 'fct'
68       is for "function."  This is used to keep cast expressions short.
703.  The Future libgss SPI
72    Once the Solaris krb5 source is resync'ed with MIT krb5 1.4 there
73    will be no further need for the 'void *context' argument to all the
74    libgss mechanisms' methods.
76    At that point it will be possible to remove this 'void *context'
77    argument from all the libgss SPI function prototypes, the main
78    result of which will be that the mechanisms' methods will then have
79    the same function signature as the corresponding GSS-API functions.
81    We can then rename all mechanisms' methods from <mech>_<gss-func> to
82    <gss-func>.  The corresponding typedefs will be renamed to
83    <gss-func>_fct.
85    The SPI, then, will be almost exactly the same as the API.
87    There will be some minor differences, primarily that some API
88    functions won't have a corresponding SPI method, such as
89    gss_release_buffer(3GSS), for example.
91    Some time later we may open the SPI to third party implementors;
92    this could be particularly useful as a way to get access to 3rd
93    party implementations of SPKM and LIPKEY (assuming any ever exist --
94    SPKM's is a very problematic specification).
96    Third party mechanisms should just export all the symbols for the
97    GSS-API functions, like MIT krb5 does, but functions which libgss
98    won't call (e.g., gss_release_buffer(3GSS)) should either not be
99    implemented or should be weak symbols.
101    Solaris native mechanisms may still provide the mechanism method
102    registration function as usual for optimization purposes -- to
103    reduce the number of calls to dlsym().
105    Mechanisms that do not provide the old method registration function
106    will be loaded as follows:
108     - libgss will look for and find the mechanism's
109       GSS_Indicate_mechs() method and will call it to discover the
110       mechanism provider's mechanism OIDs.
112     - libgss will dlsym() each mechanism provider SPI method.