|
From: Chuck L. <chu...@or...> - 2013-11-26 19:41:25
|
On Nov 25, 2013, at 3:06 PM, Steve Dickson <St...@re...> wrote: > > > On 25/11/13 14:38, Chuck Lever wrote: >> >> On Nov 25, 2013, at 2:29 PM, Steve Dickson <St...@re...> wrote: >> >>> On 25/11/13 13:53, Chuck Lever wrote: >>>> Does Linux have function calls like rpc_gss_set_svc_name(3NSL) ? I'm looking for functions documented here: >>>> >>>> http://docs.oracle.com/cd/E18752_01/html/816-1435/advrpcpt-98.html >>>> >>>> It appears Solaris and FreeBSD have these functions, but I don't see them in the Linux TI-RPC headers or library source code. Am I missing something? >>> Well I've looked in glibc and the krb5 libs.... I can't seem find it... >>> >>> Googling it... it appears AIX and FreeBSD has it.... and obviously >>> SunOS had it... I have no idea.... >> >> I'm trying to implement an RPC server in user space that supports RPCSEC GSS. The APIs in our current libtirpc implementation to handle this do not appear in the header files. For example: >> >> bool_t svcauth_gss_set_svc_name(gss_name_t name); >> char *svcauth_gss_get_principal(SVCAUTH *auth); >> >> exist in the library, but there is no public header definition for these functions, which are roughly equivalent to the rpc_gss_* APIs from Solaris. > There is no man pages for them, either... that strange... My guess is svcauth_gss_* was an early version of an RPCSEC GSSAPI, but was eventually replaced by rpc_gss_* and thus was never documented. Do we expect that the rpc_gss_* API _should_ be provided by libtirpc, and not by, say, librpcsecgss, libgssglue, or the gssapi libraries associated with krb5? (Note that krb5 appears to provide its own legacy RPC implementation under /usr/include/gssrpc ... sigh). >> Instead of simply adding the svcauth_gss_* functions to our headers, I think we'd be better off in the long run implementing the same API that is in Solaris, AIX, and FreeBSD. I'm willing to volunteer, as I think it would be little more than a shim around the existing but undocumented svcauth_ API. > Can we even do that? Legally I mean... Could there be some type > licensing issues that would prevent us from doing that? Good question for Tom Callaway. For clarity, we're talking about an RPC API that is publicly documented in the ONC+ Developers guide and provided by several independent implementations, including a liberally licensed one. > Also, the Ganesha folks are about release a new libntirpc library that is tied > to the ganesha at the moment, but maybe the documented interface is in that > lib... Not sure that would help.... I'll try to catch up with the NFS/Ganesha team and see what has been done, and explore how the FreeBSD libtirpc.so implements support for RPCSEC. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com |