> 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/* -- Chuck Lever -- 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
