On Fri, May 11, 2018 at 3:43 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > >> On May 11, 2018, at 10:34 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> >> >>> On May 10, 2018, at 5:34 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>> >>> On Thu, May 10, 2018 at 5:11 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>> >>>>> On May 10, 2018, at 4:58 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: >>>>> >>>>> On Thu, May 10, 2018 at 3:23 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>>>>> May 10 14:43:24 klimt rpc.gssd[1191]: Success getting keytab entry for 'nfs/klimt.1015granger.net@xxxxxxxxxxxxxxx' >>>>>> May 10 14:43:24 klimt rpc.gssd[1191]: gssd_get_single_krb5_cred: principal 'nfs/klimt.1015granger.net@xxxxxxxxxxxxxxx' ccache:'FILE:/tmp/krb5ccmachine_1015GRANGER.NET' >>>>>> May 10 14:43:24 klimt rpc.gssd[1191]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_1015GRANGER.NET' are good until 1526064204 >>>>>> May 10 14:43:24 klimt rpc.gssd[1191]: creating tcp client for server manet.1015granger.net >>>>>> May 10 14:43:24 klimt rpc.gssd[1191]: creating context with server host@xxxxxxxxxxxxxxxxxxxxx >>>>>> May 10 14:43:24 klimt rpc.gssd[1191]: doing downcall: lifetime_rec=76170 acceptor=host@xxxxxxxxxxxxxxxxxxxxx >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: #012handle_gssd_upcall: 'mech=krb5 uid=0 target=host@xxxxxxxxxxxxxxxxxxxxx service=nfs enctypes=18,17,16,23,3,1,2 ' (nfsd4_cb/clnt1) >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: krb5_use_machine_creds: uid 0 tgtname host@xxxxxxxxxxxxxxxxxxxxx >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: Full hostname for 'manet.1015granger.net' is 'manet.1015granger.net' >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: Full hostname for 'klimt.1015granger.net' is 'klimt.1015granger.net' >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: Success getting keytab entry for 'nfs/klimt.1015granger.net@xxxxxxxxxxxxxxx' >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_1015GRANGER.NET' are good until 1526064204 >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_1015GRANGER.NET' are good until 1526064204 >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: creating tcp client for server manet.1015granger.net >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: creating context with server host@xxxxxxxxxxxxxxxxxxxxx >>>>>> May 10 14:44:31 klimt rpc.gssd[1191]: doing downcall: lifetime_rec=76103 acceptor=host@xxxxxxxxxxxxxxxxxxxxx >>>>> >>>>> Going back to the original mail where you wrote: >>>>> >>>>> check_gss_callback_principal: acceptor=nfs@xxxxxxxxxxxxxxxxxxxxxxxx, >>>>> principal=host@xxxxxxxxxxxxxxxxxxxxx >>>>> >>>>> Where is this output on the client kernel or server kernel? >>>>> >>>>> According to the gssd output. In the callback authentication >>>>> nfs@xxxxxxxxxxxxxxxxxxxxx is authenticating to >>>>> host@xxxxxxxxxxxxxxxxxxxxx. None of them match the >>>>> "check_gss_callback_principal" output. So I'm confused... >>>> >>>> This is instrumentation I added to the check_gss_callback_principal >>>> function on the client. The above is gssd output on the server. >>>> >>>> The client seems to be checking the acceptor (nfs@xxxxxxxx) of >>>> the forward channel GSS context against the principal the server >>>> actually uses (host@klimt) to establish the backchannel GSS >>>> context. >>>> >>> >>> But according to the gssd output on the server, the server uses >>> 'nfs/klimt.1015granger.net@xxxxxxxxxxxxxxx' not "host@klimt" as the >>> principal. >>> So if that output would have been a difference but only in the domain, >>> then that would be matching my understanding. >> >> I can't even get this to work with NFS/TCP on klimt.1015granger.net, >> and a single "nfs/klimt.1015granger.net" entry in the server's keytab. >> The client complains the server is using "host@xxxxxxxxxxxxxxxxxxxxx" >> as the callback principal. >> >> I'm looking into it. > > It appears that gssproxy caches the credential on persistent storage. > See /var/lib/gssproxy/clients/* gssproxy has given me so many problems. I always turn it off. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
