From nobody Sun Jan 8 16:26:01 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 4NqjBH4Cgzz2pKts; Sun, 8 Jan 2023 16:26:15 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 4NqjBG2g2Pz46fR; Sun, 8 Jan 2023 16:26:14 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="mw4eg/oi"; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::432 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x432.google.com with SMTP id x4so347641pfj.1; Sun, 08 Jan 2023 08:26:14 -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=fSqPxVBUL9W401SgBeuQqqjtXM/nBXf6XkP9Sv1QKu0=; b=mw4eg/oiYewU7tX7x9UBWUWoTeQuwnJOpPZuavFxkfjRSG8njvtPNKCiZU4I0EUumU tEKT8jBYQEaPW2YxXkKs/M+xtagTDX7Crza5psWcj1DDoH4eZAA0WF665z4uUpv5wZOW CvH/XWLKGcIF7KgY0GTtDVmTnYmNUNwSLUIb2Nu8vtP5F8fC2NXT4QjwWJWLI8W52H43 hn9AcENqzmtpc5uKrNgvSNCL6ogW57ylhJwGLeE42LFBb7gcxjyB/5rfeC/3fMu79XUR d39lQbakv9Bbg1CBuQ7FT1sYgSe0cu/dGCZw5QN371My98xbCzubf+oeRjp4EErD1vM+ 8FYQ== 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=fSqPxVBUL9W401SgBeuQqqjtXM/nBXf6XkP9Sv1QKu0=; b=I1ZVRQefqz68ee6kMmCmonbHCqNnLfc0CbxxUHyS43dEeyakeKYHxS/rl5mBezxIHn F7fNq/ocGrmJb3SJuP18dnzz/vf3vafSXdfAp0saOugjJKrupa5n/NYSX9kwZjYVtNbB z3fu6o1fPN1xZMLgbkMKtEo/r/kt9blbUdutdb6xSFPF9oID6iIQrRF2uNbEYD09bSpN LhyEFZICsacm4iyexQxk8nGjZvlETmVBBTR24WsNmJxjSWJBiHxi2vizZ3iY5PfloX/3 D66LbSaX1HTtEaAjrGMv29wKiYZ6XRtfNmwknwt/JjVXt89cDZCyR+RicvS4i8Uz1sux aUWA== X-Gm-Message-State: AFqh2krYDtCBcMWqFeoDc0OFMqQ7Xv/cUuKTniDvQfksgO4gomOz05ps DeujcM3i+qVR8xK1tpM+djgLriRQrgnq8UbWMt/h038= X-Google-Smtp-Source: AMrXdXuQNsYAAu4QA8tX+prtdVyPeRMvD9IpKjFqm1j0tlX4iO6dOokoxZ2iyFSFRrXKyVvdSi+70AFGlNzwQzb0CaA= X-Received: by 2002:a62:e912:0:b0:579:6402:5b39 with SMTP id j18-20020a62e912000000b0057964025b39mr3890973pfh.11.1673195172677; Sun, 08 Jan 2023 08:26:12 -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: Sun, 8 Jan 2023 08:26:01 -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)[-1.000]; 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::432: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: 4NqjBG2g2Pz46fR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Sun, Jan 8, 2023 at 7:52 AM Rick Macklem wrote: > > 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). > > > The gssname argument still does take effect. The code in gssd.c does essentially > a "kinit -k " into a specific credential cache (/tmp/krb5cc_gssd > or close to > that). Then the gss_acquire_cred() uses that credential cache, which > should never > have any other TGT in it. > > > 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 suspect the problem might be that "desired_name" appears to be in the Kerberos > form (host/nfs-client.domain) and not the GSSAPI form (host@nfs-client.domain), > but I'm not sure how the code in gssd.c could change it? > > Maybe it can (re)import the name after replacing the '/' with a '@', > but I have not > tried this. > Oops, I got the above wrong. I took another look at the code and it does a... gss_display_name() of the desired name - replaces '@' with '/' in the result from gss_display_name() - uses the Kerberos variant to do essentially a "kinit -k" via Kerberos library calls, which does work ok. So, "desired_name" is in the GSSAPI form, but doesn't work when used as an argument to gss_acquire_cred(). There is a delay of several seconds (no such delay when GSS_C_NO_NAME is used as the argument) and then replies success, but with a credential I think is bogus. --> I am not sure, because after the gss_acuire_cred() reply, the gssd daemon dies, but does not leave a core dump anywhere. --> I think the kernel code (in the kgssapi) that processes the reply sees it is bogus and closes down the upcall connection to the gssd daemon. This causes the gssd daemon to terminate, due to a SIGPIPE signal. (This is what I think happens, although I am not 100% sure.) Anyhow, it definitely seems that gss_acquire_cred() is broken for this case in the Heimdal library, but I also think using GSS_C_NO_NAME is ok, since the /tmp/krb5cc_gssd credential cache is owned by root without any group./world permissions and is only used by the gssd daemon for this one purpose. rick > As above, I think the fix is ok, rick > > > > > Thanks, > > > > Ben