From nobody Wed Jan 11 22:12:38 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Nshkm06rrz2sKt3 for ; Wed, 11 Jan 2023 22:12:48 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Nshkl65dJz3sqG for ; Wed, 11 Jan 2023 22:12:47 +0000 (UTC) (envelope-from kaduk@mit.edu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=mit.edu header.s=outgoing header.b=U14QkrhC; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from kduck.mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 30BMCcdZ013649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jan 2023 17:12:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1673475163; bh=haj629PZW3aeE7S+/FniXEytWqH0oay8YzY9G8jQxw0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=U14QkrhCCI36vBRZwagzGxTRlkgDz1NVLGOLj+9dqr3UkqnjYnwx5k6co3pSSEHzU k94iad9Zip4bHdAuaEt7wkr4IaI0RMAVoybn84Z/Z9sBWbOuW7+5X8psYPpKeOQVW0 a0G53ihL1kuIh+nThE2EvSrIrn6qDQCdUfkx+vH7+HWvv2UJ3pyuH+NiODLwSbG0l3 kah9pM9nJfkEngs2TLfyaWaHThj4G9bRSDRTpoFcXtUcL0qYNk0P+U0thL8D4aKNyv ilyI5sHR5J7MYo3nl3UxNni2+C+dpu4Mu2B9q3IW/Fh8T2O6hr6izQ2PhkD9b/f4OW RLI1LH9if+9lQ== Date: Wed, 11 Jan 2023 14:12:38 -0800 From: Benjamin Kaduk To: Rick Macklem Cc: Benjamin Kaduk , Rick Macklem , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname= NFS mount option Message-ID: References: <202301072150.307LokNm093592@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-5.69 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DWL_DNSWL_LOW(-1.00)[mit.edu:dkim]; NEURAL_HAM_SHORT(-0.99)[-0.994]; DMARC_POLICY_ALLOW(-0.50)[mit.edu,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; R_DKIM_ALLOW(-0.20)[mit.edu:s=outgoing]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.11:from]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; DKIM_TRACE(0.00)[mit.edu:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Nshkl65dJz3sqG X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N Hi Rick, On Tue, Jan 10, 2023 at 08:26:23PM -0800, Rick Macklem wrote: > On Sat, Jan 7, 2023 at 6:04 PM Benjamin Kaduk wrote: > > This doesn't seem like a good long-term fix. > > If we're going to have a gssname argument, we should actually make > > it take effect, rather than silently ignoring it, which is what using GSS_C_NO_NAME > > does (it indicates the use of "any credential", which ends up meaning the > > default credential when used on a GSS initiator). > > > > It should be possible to inspect the "junk" credential from gss_acquire_cred() > > and learn more about what happened (perhaps a non-kerberos mechanismm was > > picked, or the name was in the wrong format) using various gss_inquire_*() calls, > > as a diagnostic measure. Unfortunately I don't anticipate having a huge amount of time > > to put into it anytime soon... > > > I found the underlying problem. The upcall RPC from the kernel was timing out > at 25sec and the gss_acquire_cred() call was not done at that time. > (It was close. > gss_acquire_cred() took about 27sec.) Then the kernel code would assume that > the gssd(8) daemon had gone away and closed the upcall socket. This made the > gssd(8) daemon to terminate, due to a SIGPIPE signal. Thanks for digging into this more. Wow, 27 seconds is really long for gss_acquire_cred() in normal operation! Do you happen to have a packet capture including port 88 traffic during this behavior? I kind of have to assume that it is hitting the network to incur such a long delay, as I'm not thinking of anything purely local that would take so long. (Actually, in the original model, this call would not have hit the network at all, with that being deferred until the security-context-establishment calls, but some modern extensions have changed things.) > Increasing the timeout makes it work. > > I am now "on the fence" w.r.t. leaving this patch in. As I noted, I > think it is safe > to do, since the credential cache used by the gssd(8) daemon should only have > a TGT for the host-based client credential. > Without the patch, the mount takes almost 30sec instead of a fraction > of a second > with the patch (assuming the timeout has been increased, which turns out to be > needed for the case where a user's TGT has expired and they attempt to access > the mount). > > If you really think it should be reverted, I can do that. I'm not going to specifically ask for a revert until we've tried a bit more to figure ou the root cause of the issue. The behavior is pretty weird, and I'd like to see more data before making a decision. > Thanks for your comments, rick > ps: I will be committing a change to increase the timeout. I see that, thanks for putting in the additional workaround quickly. Thanks again, Ben