Hi, I'm using nfs-ganesha 2.6.2 on Ubuntu 16.04. When a client mounts with "-t nfs4 -o sec=krb5,vers=4.0" ganesha.nfsd crashes in nfs_rpc_create_chan_v40(): Thread 11 "ganesha.nfsd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff269c700 (LWP 1118)] nfs_rpc_create_chan_v40 (clientid=0x7fffec0097b0, flags=<optimized out>) at /root/src/nfs-ganesha-2.6.2/src/MainNFSD/nfs_rpc_callback.c:591 591 if (AUTH_FAILURE(chan->auth)) { (gdb) (gdb) print chan->auth $1 = (AUTH *) 0x0 The cause seems to be the following: nfs_rpc_create_chan_v40() calls nfs_rpc_callback_setup_gss(), which calls gssd_refresh_krb5_machine_credential(). For some reason which I don't yet understand gssd_refresh_krb5_machine_credential() fails in my setup, and that makes nfs_rpc_callback_setup_gss() to return without setting chan->auth. What would be a proper fix for this problem? Rolf

On Tue, Aug 07, 2018 at 10:11:51AM -0400, Daniel Gryniewicz wrote: > Looks like a bug. I have a potential fix, can you try it? You will > need to apply auth-dummy-ganesha.patch to Ganesha, and > auth-dummy-ntirpc.patch to ntirpc. You will likely have to re-run > cmake to get ntirpc to regenerate it's exports. thank you for the patches. They solve the segfault in nfs_rpc_create_chan_v40(), but later another one occurs in clnt_vc_call(): Thread 15 "ganesha.nfsd" received signal SIGSEGV, Segmentation fault. 0x00007ffff617ba52 in clnt_vc_call (cc=0x7fffee5b2300) at /root/src/patch/libntirpc-1.6.2/src/clnt_vc.c:301 301 (cc->cc_auth->ah_cred.oa_flavor == RPCSEC_GSS) (gdb) print cc->cc_auth $8 = (AUTH *) 0x0 (gdb) bt #0 0x00007ffff617ba52 in clnt_vc_call (cc=0x7fffee5b2300) at /root/src/patch/libntirpc-1.6.2/src/clnt_vc.c:301 #1 0x00007ffff61793d3 in clnt_req_wait_reply (cc=0x7fffee5b2300) at /root/src/patch/libntirpc-1.6.2/src/clnt_generic.c:609 #2 0x00005555555a49e0 in rpc_cb_null (chan=0x7fffee5321b0, locked=false) at /root/src/patch/nfs-ganesha-2.6.2/src/MainNFSD/nfs_rpc_callback.c:672 #3 0x00005555555a6976 in nfs_test_cb_chan (clientid=0x7fffee532100) at /root/src/patch/nfs-ganesha-2.6.2/src/MainNFSD/nfs_rpc_callback.c:1326 #4 0x00005555555ec557 in nfs4_op_setclientid_confirm (op=0x7fffee550020, data=0x7fffee1fba70, resp=0x7fffee5500c0) at /root/src/patch/nfs-ganesha-2.6.2/src/Protocols/NFS/nfs4_op_setclientid_confirm.c:455 #5 0x00005555555c6672 in nfs4_Compound (arg=0x7ffff13c6f08, req=0x7ffff13c6800, res=0x7fffee552280) at /root/src/patch/nfs-ganesha-2.6.2/src/Protocols/NFS/nfs4_Compound.c:752 #6 0x00005555555c316d in nfs_rpc_process_request (reqdata=0x7ffff13c6800) at /root/src/patch/nfs-ganesha-2.6.2/src/MainNFSD/nfs_worker_thread.c:1329 #7 0x00005555555c3956 in nfs_rpc_valid_NFS (req=0x7ffff13c6800) at /root/src/patch/nfs-ganesha-2.6.2/src/MainNFSD/nfs_worker_thread.c:1554 #8 0x00007ffff6195506 in svc_vc_decode (req=0x7ffff13c6800) at /root/src/patch/libntirpc-1.6.2/src/svc_vc.c:815 #9 0x00005555555b6214 in nfs_rpc_decode_request (xprt=0x7ffff401b400, xdrs=0x7ffff404e980) ---Type <return> to continue, or q <return> to quit---q Due to the authentication failure chan->auth is set to NULL in nfs_rpc_create_chan_v40(). Eventually chan->auth is passed to clnt_vc_call() in the cc_auth field of a struct clnt_req. Rolf _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org

On Thu, Aug 09, 2018 at 12:42:48PM -0400, Daniel Gryniewicz wrote: > I'm confused, since the point of the of the patch was that > chan->auth is never NULL. It should always have an auth (whether > good or an error) in it. Can you debug and see where chan->auth is > set to NULL? With the patch nfs_rpc_callback_setup_gss() creates an AUTH structure via authnone_ncreate_dummy() and sets its ah_error.re_status to RPC_SYSTEMERROR. Afterwards nfs_rpc_create_chan_v40() checks this status with AUTH_FAILURE and sets chan->auth to NULL: chan->auth = nfs_rpc_callback_setup_gss(chan, &clientid->cid_credential); [...] if (AUTH_FAILURE(chan->auth)) { err = rpc_sperror(&chan->auth->ah_error, "failed"); LogDebug(COMPONENT_NFS_CB, "%s", err); gsh_free(err); AUTH_DESTROY(chan->auth); chan->auth = NULL; return EINVAL; }

What I don't understand now: why is it still trying to clnt_call, when it has already been told the chan is EINVAL?

On 08/09/2018 02:17 PM, Rolf Anders wrote: > On Thu, Aug 09, 2018 at 12:42:48PM -0400, Daniel Gryniewicz wrote: >> I'm confused, since the point of the of the patch was that >> chan->auth is never NULL.  It should always have an auth (whether >> good or an error) in it.  Can you debug and see where chan->auth is >> set to NULL? > > With the patch nfs_rpc_callback_setup_gss() creates an AUTH structure > via authnone_ncreate_dummy() and sets its ah_error.re_status to > RPC_SYSTEMERROR. Afterwards nfs_rpc_create_chan_v40() checks this status > with AUTH_FAILURE and sets chan->auth to NULL: > > chan->auth = nfs_rpc_callback_setup_gss(chan, >                 &clientid->cid_credential); > [...] > if (AUTH_FAILURE(chan->auth)) { >     err = rpc_sperror(&chan->auth->ah_error, "failed"); > >     LogDebug(COMPONENT_NFS_CB, "%s", err); >     gsh_free(err); >     AUTH_DESTROY(chan->auth); >     chan->auth = NULL; >     return EINVAL; > } > Gotcha, thanks.  I'll look into it. Daniel