Description of problem: Update to 1.6.1-17.el5 breaks gss/krb5 based NFS4 which worked fine with 1.5-29. Trying to mount a share fails and rpc.gssd creates | # rpc.gssd -k /etc/keytab.nfs4 -vvvvvvvvvv -f -rrrrr | Using keytab file '/etc/keytab.nfs4' | Processing keytab entry for principal 'nfs/bristol.intern.sigma-chemnitz.de' | We will use this entry (nfs/bristol.intern.sigma-chemnitz.de) | Using (machine) credentials cache: 'MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE' | handling krb5 upcall | Using keytab file '/etc/keytab.nfs4' | INFO: Credentials in CC 'MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE' are good until 1197579870 | using MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE as credentials cache for machine creds | using environment variable to select krb5 ccache MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE | creating context using fsuid 0 (save_uid 0) | creating tcp client for server ensc-virt.intern.sigma-chemnitz.de | creating context with server nfs.sigma-chemnitz.de | WARNING: Failed to create krb5 context for user with uid 0 for server ensc-virt.intern.sigma-chemnitz.de | WARNING: Failed to create krb5 context for user with uid 0 with credentials cache MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE for server ensc-virt.intern.sigma-chemnitz.de | WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server ensc-virt.intern.sigma-chemnitz.de | doing error downcall | destroying client clnt4d | destroying client clnt4c messages. Downgrading to older krb5-libs gives | # rpm -Uvh krb5-libs-1.5-29.x86_64.rpm --nodeps --force | # rpc.gssd -k /etc/keytab.nfs4 -vvvvvvvvvv -f -rrrrr | Using keytab file '/etc/keytab.nfs4' | Processing keytab entry for principal 'nfs/bristol.intern.sigma-chemnitz.de' | We will use this entry (nfs/bristol.intern.sigma-chemnitz.de) | Using (machine) credentials cache: 'MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE' | handling krb5 upcall | Using keytab file '/etc/keytab.nfs4' | INFO: Credentials in CC 'MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE' are good until 1197579811 | using MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE as credentials cache for machine creds | using environment variable to select krb5 ccache MEMORY:/tmp/krb5cc_machine_SIGMA-CHEMNITZ.DE | creating context using fsuid 0 (save_uid 0) | creating tcp client for server ensc-virt.intern.sigma-chemnitz.de | creating context with server nfs.sigma-chemnitz.de | DEBUG: serialize_krb5_ctx: lucid version! | prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 Related keys are [root@ensc-virt ~]# klist -k /etc/keytab.nfs4 -e Keytab name: FILE:/etc/keytab.nfs4 KVNO Principal ---- -------------------------------------------------------------------------- 5 nfs/ensc-virt.intern.sigma-chemnitz.de (AES-256 CTS mode with 96-bit SHA-1 HMAC) 5 nfs/ensc-virt.intern.sigma-chemnitz.de (Triple DES cbc mode with HMAC/sha1) 5 nfs/ensc-virt.intern.sigma-chemnitz.de (DES cbc mode with RSA-MD5) [root@bristol tmp]# klist -k /etc/keytab.nfs4 -e Keytab name: FILE:/etc/keytab.nfs4 KVNO Principal ---- -------------------------------------------------------------------------- 6 nfs/bristol.intern.sigma-chemnitz.de (DES cbc mode with RSA-MD5) Both machines are x86_64 ones; but ensc-virt is running F8 Version-Release number of selected component (if applicable): krb5-libs-1.6.1-17.el5 nfs-utils-1.0.9-24.el5 How reproducible: 100%
Serverside gives | # env -i KRB5_KTNAME=/etc/keytab.nfs4 /usr/sbin/rpc.svcgssd -vvvvvvvrrrrrrrrrrrrf | | sname = nfs/bristol.intern.sigma-chemnitz.de | DEBUG: serialize_krb5_ctx: lucid version! | ERROR: prepare_krb5_rfc_cfx_buffer: not implemented | serialize_krb5_ctx: prepare_krb5_*_buffer failed (retcode = -1) | ERROR: failed serializing krb5 context for kernel | WARNING: handle_nullreq: serialize_context_for_kernel failed | sending null reply with 1.6.1-17 and | sname = nfs/bristol.intern.sigma-chemnitz.de | DEBUG: serialize_krb5_ctx: lucid version! | prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 | doing downcall with 1.5-29
I think you've hit a place where the support for multiple types of ciphers doesn't jive between the kernel, nfs-utils and the Kerberos libraries. This error message is triggered by a mismatch between nfs-utils and the Kerberos GSSAPI library. Can you re-key one of the affected services (nfs/ensc-virt, for example) with just a 'des-cbc-crc:normal' key and try again? That should let you work around this for the time being.
The librpcsecgss library's in nfs-utils, and I'm pretty sure that's where any code changes which might have to be made will have to be made. Reassigning.
Nalin, What needs to happen?
Depending on the lucid context's 'proto' field, gssd uses either prepare_krb5_rfc1964_buffer() or prepare_krb5_rfc_cfx_buffer(). The field's value, in turn, is controlled by the type of the encryption key used in the established context. If the kernel supports newer enctypes, we should backport prepare_krb5_rfc_cfx_buffer() (known as prepare_krb5_rfc4121_buffer() in newer releases) and pick up a krb5 patch Kevin Coffman provided that we also need for this case. Otherwise, if we're still seeing this with krb5 newer than 1.6.1-31 (which fixed bug #447672), we'll need to figure out why gss_krb5_set_allowable_enctypes() isn't having the desired effect.
> If the kernel supports newer enctypes.... RHEL5 does not have that support.. at least I didn't put it... > Otherwise, if we're still seeing this with krb5 newer than 1.6.1-31 (which > fixed bug #447672), we'll need to figure out why > gss_krb5_set_allowable_enctypes() isn't having the desired effect. Well that routine seems to be in your world... so do you have any suggestions on how do debug ig?
(In reply to comment #6) > > Otherwise, if we're still seeing this with krb5 newer than 1.6.1-31 (which > > fixed bug #447672), we'll need to figure out why > > gss_krb5_set_allowable_enctypes() isn't having the desired effect. > > Well that routine seems to be in your world... so do you have > any suggestions on how do debug it? If we're still seeing it with current packages, a wire trace of traffic between the NFS client and the KDC should tell us which encryption types are being requested of the KDC by the client.
Enrico, Are you still seeing this problem with a more recent nfs-utils? I'm not seeing this problem is nfs-utils-1.0.9-47