Re: [Libtirpc-devel] RPCSEC GSS API

[Chuck L. <chu...@or...>]

On Nov 26, 2013, at 4:27 PM, Simo Sorce <si...@re...> wrote:

> On Tue, 2013-11-26 at 16:13 -0500, Chuck Lever wrote:
>> On Nov 26, 2013, at 3:42 PM, Simo Sorce <si...@re...> wrote:
>> 
>>> On Tue, 2013-11-26 at 15:13 -0500, Chuck Lever wrote:
>>>> On Nov 26, 2013, at 2:54 PM, Simo Sorce <si...@re...> wrote:
>>>> 
>>>>> On Tue, 2013-11-26 at 14:41 -0500, Chuck Lever wrote:
>>>>>> 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).
>>>>> 
>>>>> Not only it provides it but it is much better than the kludge in
>>>>> libtirpc that relies on glibc weak symbols to work at all.
>>>> 
>>>> If I understand what you are referring to, that was Drepper's
>> solution to having both the glibc and the libtirpc implementations
>> co-exist.  At some point we were supposed to get rid of that kludge
>> and all vestiges of the glibc implementation, and just use libtirpc.
>>>> 
>>>>> I got such a nasty bug by a symbol available in glibc but not in
>>>>> libtirpc that I switched one of my projects to MIT's gssrpc and
>> won't
>>>>> look back.
>>>> 
>>>> Is there a bugzilla report?
>>>> 
>>>>> At least with MIT gssrpc there is no risk of symbol clashes.
>>>> 
>>>> On the other hand, there is no TI-RPC support in the MIT gssrpc,
>> and thus no hope of an interoperable IPv6-enabled RPC implementation
>> there.
>>>> 
>>>>> 
>>>>>>>> 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.
>>>>> 
>>>>> 
>>>>> Can we all settle on a single library and improve that one ?
>>>> 
>>>> I'd like that.  On Linux, that one is supposed to be libtirpc,
>> which is quite adequate for general use.
>>>> 
>>>> The NFS/Ganesha project has additional requirements, and does not
>> need to cleave to the Sun standard APIs.
>>> 
>>> The 2 interfaces could be provided by the same library guaranteeing
>> code
>>> reuse and improvements get to both.
>> 
>> It's easy to agree to that in the abstract.  Since I haven't seen the
>> Ganesha code, it's more difficult to say whether it is appropriate for
>> generic use, or even whether some of their work can be ported into
>> libtirpc.
>> 
>> The line we drew in the sand years ago was "don't change the existing
>> Sun APIs."  Bi-directional RPC threatened to break API and/or ABI
>> compatibility.  If a merge can be accomplished without breaking
>> things, then we could consider it.
>> 
>> But I'm not sure I would want to expose any bi-directional API as a
>> published interface unless there was agreement among other library
>> implementations that we had hit upon the right API for it.  I think
>> that's the process that the Ganesha folks have balked at.  Since they
>> really don't need a published and agreed to API, there isn't a strong
>> reason for them to pursue it.
>> 
>> Btw, libtirpc is supposed to be MT-safe.  It is on Solaris, for
>> example.  If we don't have MT safety on Linux, that should be
>> considered a bug.  I suspect that Ganesha has some rather specific
>> requirements there, however, that might not fit with a generic API.
>> 
>>> 
>>>> Having a separate implementation there is appropriate.
>>>> 
>>>> I don't find that MIT's gssrpc has similar justification.
>>> 
>>> Until there are symbol clashes between libtirpc and glibc it is
>> fully
>>> justified unfortunately.
>> 
>> As I understand it, gssrpc was forked because the glibc RPC
>> implementation did not have GSS support.  No idea why the support was
>> not contributed to or accepted by the glibc community.  I didn't
>> realize this one existed until today.
>> 
>> The glibc folks were also not interested in TI-RPC for IPv6 support.
>> Their stated reason was that "RPC sucks!!1! and we don't want to
>> maintain it in glibc any more."  So we ported libtirpc to Linux, since
>> it has IPv6 capability, and also the potential for standardized GSS
>> support.  Our plan was to get rid of the legacy glibc RPC
>> implementation eventually, but that seems to have lost its resources.
>> 
>>> If we can get to avoid those issues in libtirpc I am all for
>> electing it
>>> the library to go.
>> 
>> I agree the behavior you describe sounds undesirable.  If there is a
>> bug report we can start there.
>> 
> I honestly do not recall if I opened a bug report, and if I did where :)
> 
> But I can tell you what made the whole thing blow up.
> glibc has xdr_quad_t while libtirpc does not.
> 
> I used that symbol in my .x files, so for most of the stuff libtirpc was
> used, but when xdr_quad_t was encountered the gic one was resolved. Of
> course the context structure between glibc and libtirpc has diverged
> incompatibly so as soon as glibc's implementation tried to access the
> context fireworks ensued.

It looks like xdr_quad_t() is not the only missing XDR function.  xdr_float(), xdr_vector(), and xdr_int8_t() are just a few that appear in /usr/include/rpc/xdr.h, but not in libtirpc.

We do want libtirpc on Linux to be as compatible with the legacy glibc RPC implementation as possible.  It wouldn't be unreasonable to add these functions to libtirpc, IMO.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com