From nobody Sun Jan 8 02:03:55 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 4NqL3X0Lzvz2r1H1; Sun, 8 Jan 2023 02:04:08 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 4NqL3W5LvHz4H5t; Sun, 8 Jan 2023 02:04:07 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa33.google.com with SMTP id b81so2384234vkf.1; Sat, 07 Jan 2023 18:04:07 -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=Xi6olaEu9/D6jLQFTUt/Eztt6vi/Ulw/puoG/wM5HPM=; b=NbVGO4y2IqLyMrfdTjWtVxgpewU4U7zPdmERdf47Yv8K93UP5gxtuEq0H/K1Jtc16S qw3CMsUHwlej3MAbXW7NhjdNAXO6sCSCAmczhUY638kFyLTJxqGMXSZHypOLgoWCXcG9 Zd42uVAYldC650VZkyGO4EE5uuuVtbCGERlv/fQsJzJTqZiPOs1RGJgJXJ5IbyPcVEH0 cMBHn9ZrBrXKkv2KzvBN1GTM2LySLZhGymHN95rZj+CISmoPxvkzvKolIJy/M9zeEucN QsUcC6bPHrIQPvkA3vrLOErzobTsRGciX8JgklQCmGTv2zWhCQZ9PyHudqrYSCV1xJYb 1+Uw== 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=Xi6olaEu9/D6jLQFTUt/Eztt6vi/Ulw/puoG/wM5HPM=; b=xQewv0P+Qeg3EN26IL1XOdKkNwIRhCiq7B3WEl64lMQFL6EBDsCqBgnQom2Z8pXfDZ 1g0Z7lf4i3KJblcEOx1lJVSHaZkLJdvCUrw2lJn4OtFwTt4UqQ2JHyXPYj2C7+x+CHfR 9cVPcxau0RaLKZaWWWF8AiHaula0nt02TeM/lJSfVpXvzxAFzox1WCCyuRZozXu2P3uk aggj41cIeRbfKn0mzh6zDSwSHkH3jR4/BRbDeOIUOV0pNCKFA+iRxFX5DfcSg5zWJTcJ VHAtJ6avdHiu6VxD8n2csLw42LX3gnOMu663ttS/fVyxqvppEsuETLNTDBGXJ2F/PfVl O1Zw== X-Gm-Message-State: AFqh2kow7H3KcnUCCfgVNuAH49dmmOaa3dnYVY3BVj/1LhfKASLgPIW6 X9uxC+nNnf4H/klA0zuyUIYyCwJQARUz6d5Y2usH/G8X X-Google-Smtp-Source: AMrXdXtD9+YZMmBVCst9o1KNN/zl6Kxoj9HsWIbLx0oUMfcC8Fcld9MSOByjloEUdWe4kafnQotIfGXjPN0GriaoVFo= X-Received: by 2002:a1f:940a:0:b0:3bd:e439:84e4 with SMTP id w10-20020a1f940a000000b003bde43984e4mr6905343vkd.11.1673143446219; Sat, 07 Jan 2023 18:04:06 -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: <202301072150.307LokNm093592@gitrepo.freebsd.org> From: Benjamin Kaduk Date: Sat, 7 Jan 2023 18:03:55 -0800 Message-ID: Subject: Re: git: c33509d49a6f - main - gssd: Fix handling of the gssname= NFS mount option To: Rick Macklem Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="000000000000c531cc05f1b71015" X-Rspamd-Queue-Id: 4NqL3W5LvHz4H5t X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000c531cc05f1b71015 Content-Type: text/plain; charset="UTF-8" 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... Thanks, Ben --000000000000c531cc05f1b71015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jan 7, 2023 at 1:50 PM Rick Mackl= em <rmacklem@freebsd.org>= wrote:
The branch main has been updated by rmacklem:

URL: https://cgit.= FreeBSD.org/src/commit/?id=3Dc33509d49a6fdcf86ef280a78f428d3cb7012c4a
commit c33509d49a6fdcf86ef280a78f428d3cb7012c4a
Author:=C2=A0 =C2=A0 =C2=A0Rick Macklem <rmacklem@FreeBSD.org>
AuthorDate: 2023-01-07 21:49:25 +0000
Commit:=C2=A0 =C2=A0 =C2=A0Rick Macklem <rmacklem@FreeBSD.org>
CommitDate: 2023-01-07 21:49:25 +0000

=C2=A0 =C2=A0 gssd: Fix handling of the gssname=3D<name> NFS mount op= tion

=C2=A0 =C2=A0 If an NFS mount using "sec=3Dkrb5[ip],gssname=3D<name= >" is
=C2=A0 =C2=A0 done, the gssd daemon fails.=C2=A0 There is a long delay
=C2=A0 =C2=A0 (several seconds) in the gss_acquire_cred() call and then
=C2=A0 =C2=A0 it returns success, but the credentials returned are
=C2=A0 =C2=A0 junk.

=C2=A0 =C2=A0 I have no idea how long this has been broken, due to some
=C2=A0 =C2=A0 change in the Heimdal gssapi library call, but I suspect
=C2=A0 =C2=A0 it has been quite some time.

=C2=A0 =C2=A0 Anyhow, it turns out that replacing the "desired_name&qu= ot;
=C2=A0 =C2=A0 argument with GSS_C_NO_NAME fixes the problem.
=C2=A0 =C2=A0 Replacing the argument should not be a problem, since the
=C2=A0 =C2=A0 TGT for the host based initiator credential in the default =C2=A0 =C2=A0 keytab file should be the only TGT in the gssd'd credenti= al
=C2=A0 =C2=A0 cache (which is not the one for uid 0).

=C2=A0 =C2=A0 I will try and determine if FreeBSD13 and/or FreeBSD12
=C2=A0 =C2=A0 needs this same fix and will MFC if they need the fix.

=C2=A0 =C2=A0 This problem only affected Kerberized NFS mounts when the
=C2=A0 =C2=A0 "gssname" mount option was used.=C2=A0 Other Kerber= ized NFS
=C2=A0 =C2=A0 mount cases already used GSS_C_NO_NAME and work ok.
=C2=A0 =C2=A0 A workaround if you do not have this patch is to do a
=C2=A0 =C2=A0 "kinit -k host/FQDN" as root on the machine, follow= ed by
=C2=A0 =C2=A0 the Kerberized NFS mount without the "gssname" moun= t
=C2=A0 =C2=A0 option.



Hi Rick,

This doesn't seem like a good long-= term fix.
If we're going to have a gssname argument, we shoul= d 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 cre= dential when used on a GSS initiator).

It should b= e possible to inspect the "junk" credential from gss_acquire_cred= ()
and learn more about what happened (perhaps a non-kerberos mec= hanismm was
picked, or the name was in the wrong format)=C2=A0 us= ing various gss_inquire_*() calls,
as a diagnostic measure.=C2=A0= Unfortunately I don't anticipate having a huge amount of time
to put into it anytime soon...

Thanks,

Ben
--000000000000c531cc05f1b71015--