From nobody Wed Jan 11 04:26:23 2023 X-Original-To: dev-commits-src-all@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 4NsF4c15wRz2sQgB; Wed, 11 Jan 2023 04:26:40 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4NsF4Z72jTz41s9; Wed, 11 Jan 2023 04:26:38 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=jB20ZWZK; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::42b as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x42b.google.com with SMTP id a30so10495827pfr.6; Tue, 10 Jan 2023 20:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=BCbmfbE/oHQ54jSc/jRm023WmgS2T163XcbTke5OFtQ=; b=jB20ZWZK//nymkRb85ys+dMbdih/cE502LgVK3u0iHvFNtzPXaaCDe5f56PswKYevt A+Skct/jLbuTgn/koBWqsv8YRxpsijPAY2m6XLqmlBzp/TU3CbJHkwPVmjp5W6Y3KRY1 uBjozBmu+PwnIzTsZ96V0TPVwiKIvJrUZrwanHJb1OMoOPEor5kBQqVGWhSRkBupI/G8 /dtWBz6KMrsyoEDLymHti/Z8rCOdwE47LN2SOEBFjEicFZJkkexJhzQZ3rbKmdYB5IAA FpV90FsI+QCfBzXhA5fQwG6b76QTEooeFvDFv8R5/RQ3StkwQKmLp26+qJDDeSjpnABh gHbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BCbmfbE/oHQ54jSc/jRm023WmgS2T163XcbTke5OFtQ=; b=jchIxuGJsexfa4FP3o1UXCEbPGB6cTCjW3rzlSHRcR07Y2S1QuZhen6Au1YXkaIyom ZXCH7f9vs5nOj/Z+ShisVlZnAMUmZZaq85OPZCrEP/MAXo7H4lOHPaXNxeMz+JtdBNiZ KXmyTsyGY/SIhr/1wJCw+OpcS/R8q/0YTeFoEKjYHyGMAjMcyHeSJFSWLiyugZ9pkd40 nLc28lwgaUkwkzkEq6qigGjz7qZAXfIJK06GCbkw0XDNS5CvxESfciAPAepMmlQR6lY2 aYkNo/gzumdEnWjpW6QOfiOnFuxGqVKv2D7odZpjYWI4Z2QpN+nmJhi7AZ8Sh3eNef/H JGtQ== X-Gm-Message-State: AFqh2kpo3/OvHPA+EHtBssTSybnOZJKjeffn6Z4P6FRnOuuxS67sB1Ym quyzF4FMcwXRd0XKiYNeDFPkwEjgrz423h8hxw== X-Google-Smtp-Source: AMrXdXtSAtDqw4+u36ITk3LIKsDBfM7RkE8hyyJas9bV8H1O3amXt9pCktrPHQJO6Y01VagQ+srimz63HRJoVlv0bfY= X-Received: by 2002:a63:d018:0:b0:477:cce0:28f8 with SMTP id z24-20020a63d018000000b00477cce028f8mr5289424pgf.89.1673411197383; Tue, 10 Jan 2023 20:26:37 -0800 (PST) List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 References: <202301072150.307LokNm093592@gitrepo.freebsd.org> In-Reply-To: From: Rick Macklem Date: Tue, 10 Jan 2023 20:26:23 -0800 Message-ID: Subject: Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname= NFS mount option To: Benjamin Kaduk Cc: Rick Macklem , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42b:from]; TAGGED_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; FREEMAIL_FROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4NsF4Z72jTz41s9 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Sat, Jan 7, 2023 at 6:04 PM Benjamin Kaduk wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca > > On Sat, Jan 7, 2023 at 1:50 PM Rick Macklem wrote: >> >> The branch main has been updated by rmacklem: >> >> URL: https://cgit.FreeBSD.org/src/commit/?id=c33509d49a6fdcf86ef280a78f428d3cb7012c4a >> >> commit c33509d49a6fdcf86ef280a78f428d3cb7012c4a >> Author: Rick Macklem >> AuthorDate: 2023-01-07 21:49:25 +0000 >> Commit: Rick Macklem >> CommitDate: 2023-01-07 21:49:25 +0000 >> >> gssd: Fix handling of the gssname= NFS mount option >> >> If an NFS mount using "sec=krb5[ip],gssname=" is >> done, the gssd daemon fails. There is a long delay >> (several seconds) in the gss_acquire_cred() call and then >> it returns success, but the credentials returned are >> junk. >> >> I have no idea how long this has been broken, due to some >> change in the Heimdal gssapi library call, but I suspect >> it has been quite some time. >> >> Anyhow, it turns out that replacing the "desired_name" >> argument with GSS_C_NO_NAME fixes the problem. >> Replacing the argument should not be a problem, since the >> TGT for the host based initiator credential in the default >> keytab file should be the only TGT in the gssd'd credential >> cache (which is not the one for uid 0). >> >> I will try and determine if FreeBSD13 and/or FreeBSD12 >> needs this same fix and will MFC if they need the fix. >> >> This problem only affected Kerberized NFS mounts when the >> "gssname" mount option was used. Other Kerberized NFS >> mount cases already used GSS_C_NO_NAME and work ok. >> A workaround if you do not have this patch is to do a >> "kinit -k host/FQDN" as root on the machine, followed by >> the Kerberized NFS mount without the "gssname" mount >> option. >> > > > Hi Rick, > > 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. 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. Thanks for your comments, rick ps: I will be committing a change to increase the timeout. > Thanks, > > Ben