Path: csiph.com!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: "Tyler W. Ross" Newsgroups: linux.debian.bugs.dist,linux.kernel,linux.debian.kernel Subject: Bug#1120598: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2 Date: Wed, 19 Nov 2025 18:30:01 +0100 Message-ID: References: X-Original-To: Scott Mayhew , Salvatore Bonaccorso X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Wed Nov 19 17:23:10 2025 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: -2.399 Reply-To: "Tyler W. Ross" , 1120598@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: debian-kernel@lists.debian.org X-Debian-Pr-Message: followup 1120598 X-Debian-Pr-Package: src:linux X-Debian-Pr-Keywords: upstream X-Debian-Pr-Source: linux Feedback-ID: 101639484:user:proton X-Pm-Message-ID: 442ec894d7bb6d6e7ea57276a8a66da3e738fdc0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Debian-Message: from BTS X-Mailing-List: archive/latest/1937614 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 174 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Trond Myklebust , Chuck Lever , Anna Schumaker , "1120598@bugs.debian.org" <1120598@bugs.debian.org>, Jeff Layton , NeilBrown , Steve Dickson , Olga Kornievskaia , Dai Ngo , Tom Talpey , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, Simon Josefsson X-Original-Date: Wed, 19 Nov 2025 17:19:15 +0000 X-Original-Message-ID: <0e7b3c83-df95-4f5f-b865-85c168274a8d@TylerWRoss.com> X-Original-References: <176298368872.955.14091113173156448257.reportbug@nfsclient-sid.ipa.twrlab.net> Xref: csiph.com linux.debian.bugs.dist:1270828 linux.kernel:1743504 linux.debian.kernel:90157 On 11/19/25 6:36 AM, Scott Mayhew wrote: > While I still assert that if you want to use the stronger encryption > types with NFS, then you should prioritize those encryption types higher > in your kerberos configuration... after discussing this yesterday with > Olga I think the above scenario should probably work too. There was no intent or attempt to specify encryption types in the original configuration. Fiddling with enctypes only came up in the course of troubleshooting. This issue was found/replicated by: 1. Configuring a stock Debian 13 client using ipa-client-install against a freshly deployed Fedora 43 IPA instance. 2. Adding a krb5 NFS entry in fstab 3. Installing and enabling gssproxy (use-gss-proxy=3D1 in nfs.conf) 4. Configuring gssproxy for constrained delegation as described in the docs: [service/nfs-client] mechs =3D krb5 cred_store =3D keytab:/etc/krb5.keytab cred_store =3D ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U cred_usage =3D initiate allow_any_uid =3D yes impersonate =3D true euid =3D 0 5. Allowing constrained delegation on the IPA/KDC side I think this should be a working configuration: it shouldn't be necessary to change the enctypes from default for this to work. But the above results in the aes256-cts-hmac-sha1-96 machine credential and aes256-cts-hmac-sha384-192 client ticket situation. > I just sent a patch that makes that happen, but I forgot to add > "--in-reply-to" my "git send-email" command, so here's the link: >=20 > https://lore.kernel.org/linux-nfs/20251119133231.3660975-1-smayhew@redhat= .com/T/#u Thanks, Scott. So it's technically possible for the machine and client credentials to have mismatched enctypes? There are just assumptions (like the slack variable calculations) that need to be changed to support that? I'm also wondering if the gssproxy behavior is correct. I obviously don't understand all the nuance here, but it appears gssproxy is requesting the service ticket with a different preference/order of enctypes -- which leads to this mismatch situation. Looking at the KDC logs (below), the protocol transition request has enctypes matching the default permitted_enctypes described in krb5.conf(5) (i.e., with aes256-cts-hmac-sha1-96 first). But then the constrained delegation request lists aes256-cts-hmac-sha384-192 first, which I assume indicates preference and is why that enctype is issued. Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): TGS_REQ (8 et= ypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-= hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-= sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia25= 6-cts-cmac(26)}) 10.108.2.105: ISSUE: authtime 1763506600, etypes {rep=3Dae= s256-cts-hmac-sha1-96(18), tkt=3Daes256-cts-hmac-sha384-192(20), ses=3Daes2= 56-cts-hmac-sha1-96(18)}, host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET for = host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): ... PROTOCOL-= TRANSITION s4u-client=3Djsmith@IPA.TWRLAB.NET Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): closing down = fd 4 Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): TGS_REQ (4 et= ypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes25= 6-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.108.2.105: ISSUE: = authtime 1763506600, etypes {rep=3Daes256-cts-hmac-sha1-96(18), tkt=3Daes25= 6-cts-hmac-sha384-192(20), ses=3Daes256-cts-hmac-sha384-192(20)}, host/nfsc= lient.ipa.twrlab.net@IPA.TWRLAB.NET for nfs/nfssrv.ipa.twrlab.net@IPA.TWRLA= B.NET Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): ... CONSTRAIN= ED-DELEGATION s4u-client=3Djsmith@IPA.TWRLAB.NET Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): closing down = fd 11 >=20 > -Scott >=20 >> >>> That's exactly the case: the machine credential is >>> aes256-cts-hmac-sha1-96. >>> >>> So, taking a step back for context/background: this issue was escalated= to >>> me by someone attempting to use constrained delegation via gssproxy. In= the >>> course of troubleshooting that, we found (by examining the krb5kdc logs= on >>> the IPA server) that the NFS service ticket acquired by gssproxy had an >>> aes256-cts-hmac-sha384-192 session key. >>> >>> Not understanding that the machine and user tickets must having matchin= g >>> enctypes, I ended up down this rabbit hole thinking the problem >>> was with the SHA2 enctypes. Sorry to bring you all with me on that >>> misadventure. >>> >>> >>> >>> The actual issue at hand then seems to be that gssproxy is requesting (= and >>> receiving) a service ticket with an unusable (for the NFS mount) enctyp= e, >>> when performing constrained delegation/S4U2Proxy. >>> >>> krb5kdc logs of gssproxy performing S4U2Self and S4U2Proxy:Nov 18 18:06= :51 >>> directory.ipa.twrlab.net krb5kdc[8463](info): TGS_REQ (8 etypes >>> {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), >>> aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), >>> UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), >>> camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.108.2.105: ISSU= E: >>> authtime 1763506600, etypes {rep=3Daes256-cts-hmac-sha1-96(18), >>> tkt=3Daes256-cts-hmac-sha384-192(20), ses=3Daes256-cts-hmac-sha1-96(18)= }, >>> host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET for >>> host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET >>> Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): >>> ... PROTOCOL-TRANSITION s4u-client=3Djsmith@IPA.TWRLAB.NET >>> Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): closing d= own >>> fd 4 >>> Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): TGS_REQ (= 4 >>> etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), >>> aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.108.2.105= : >>> ISSUE: authtime 1763506600, etypes {rep=3Daes256-cts-hmac-sha1-96(18), >>> tkt=3Daes256-cts-hmac-sha384-192(20), ses=3Daes256-cts-hmac-sha384-192(= 20)}, >>> host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET for >>> nfs/nfssrv.ipa.twrlab.net@IPA.TWRLAB.NET >>> Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): ... >>> CONSTRAINED-DELEGATION s4u-client=3Djsmith@IPA.TWRLAB.NET >>> Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): closing d= own >>> fd 11 >>> >>> >>> On the Fedora 43 client, gssproxy also acquires an >>> aes256-cts-hmac-sha384-192 service ticket, but the machine credential i= s >>> aes256-cts-hmac-sha384-192 and everything works as-ex >>> pected. >> >> I'm looping in here the gssproxy maintainer as well. Simon, this is >> about https://bugs.debian.org/1120598 . I assume there is nothing on >> gssroxy side which can be done to warn about the situation, quoting >> again: >> >>> The actual issue at hand then seems to be that gssproxy is requesting (= and >>> receiving) a service ticket with an unusable (for the NFS mount) enctyp= e, >>> when performing constrained delegation/S4U2Proxy. >> >> ? >> >> Regards, >> Salvatore >> >=20 TWR