Received-SPF: pass (google.com: domain of linux-nfs+bounces-28-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <97AE695C-8F9F-4E9C-9460-427C284FBD32@oracle.com>
In-Reply-To: <97AE695C-8F9F-4E9C-9460-427C284FBD32@oracle.com>
From: Olga Kornievskaia <aglo@umich.edu>
Date: Tue, 21 Nov 2023 20:07:36 -1000
Message-ID: <CAN-5tyHxvTevgM38q94W4e+rBzYu7tWqDHVMNcFQ5GT3uNArCw@mail.gmail.com>
Subject: Re: changes to struct rpc_gss_sec
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Olga Kornievskaia <kolga@netapp.com>, Steve Dickson <SteveD@redhat.com>, 
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Chuck,

A quick reply as I'm on vacation but I can take a look when I get
back. I'm just thinking there must be a reason why gssd is using the
authgss api and not calling the rpc_gss one.

On Tue, Nov 21, 2023 at 6:59=E2=80=AFAM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
> Hey Olga-
>
> I see that f5b6e6fdb1e6 ("gss-api: expose gss major/minor error in
> authgss_refresh()") added a couple of fields in structure rpc_gss_sec.
> Later, there are some nfs-utils changes that start using those fields.
>
> That breaks building the latest upstream nfs-utils on Fedora 38, whose
> current libtirpc doesn't have those new fields.
>
> IMO struct rpc_gss_sec is part of the libtirpc API/ABI, thus we really
> shouldn't change it.
>
> Instead, if gssd needs GSS status codes, can't it call
> rpc_gss_seccreate(3), which explicitly takes a struct
> rpc_gss_options_ret_t * argument?
>
> ie, just replace the authgss_create_default() call with a call to
> rpc_gss_seccreate(3) ....
>
>
> --
> Chuck Lever
>
>
>