12:46 p.m.
Yeah, sadly libntirpc (and ntirpc implementations generally)
actually aren't able to establish connections as clients. I haven't looked
at the GSS auth code, but will do so. I don't think there's any reason it
would "require" CLIENT (it's just more bytes that need to be on the wire).
But my experience with the CLIENT functions from the V3 proxy was that I
couldn't even get it to establish connections. (see FSAL_PROXY_V3/rpc.c).
Would you mind pasting your in-progress code? (if you got it to work, that
would be *fantastic*)
On Thu, Sep 17, 2020 at 10:21 AM Jo Seaton <jo(a)petagene.com> wrote:
Hi all,
I've been working on re-adding GSS/Kerberos authentication support to the PROXY (V4)
FSAL, with a mind to eventually also adding Kerberos delegation support for completeness.
I've been having some issues I was hoping to get some feedback on.
The first issue I've been having is to do with the GSS code in libntirpc.
I'm calling authgss_ncreate_default with a valid CLIENT * and service name, and
hopefully a reasonable struct rpc_gss_sec. This fails, because the call to gss_verify_mic
inside authgss_refresh fails. This appears to be because authgss_verify fills a relevant
buffer (gd->gc_wire_verf) with <empty>, which originally comes from cc_verf in
the clnt code (via the start of authgss_validate). Specifically I'm looking at
clnt_req's cc_verf which gets used for AUTH_VALIDATE in clnt_generic.c, and always
seems to have the same "_null_auth" value - which seems surprising to me! If
anyone can give me some insight into what exactly cc_verf is supposed to contain that
might help me fix it. Working around it by ignoring the result of gss_verify_mic does seem
to work OK.
The second issue is to do with the structure of the PROXY FSAL.
It appears that it largely handles requests "manually", calling the relevant
xdr_* functions, and reading/writing to sockets itself. The GSS auth code on the other
hand, seems to require use of CLIENT *, which in my understanding means handing
responsibility for the socket to that CLIENT *. These two approaches appear incompatible
to me. I've made some reasonable progress rewriting PROXY with clnt_req_* functions,
similar to nfs_rpc_callback.c, but if anyone has any feedback on a) why the original
approach (ffilz suggests those functions didn't used to be threadsafe?) b) the most
sensible thing to do now, it would be very much appreciated.
Anyway any feedback is very welcome, I'm very new to both Ganesha and GSS/Kerberos.
Many thanks,
Jo
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org