Received-SPF: pass (google.com: domain of linux-nfs+bounces-110-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <97AE695C-8F9F-4E9C-9460-427C284FBD32@oracle.com>
 <CAN-5tyHxvTevgM38q94W4e+rBzYu7tWqDHVMNcFQ5GT3uNArCw@mail.gmail.com> <6F0CCBAF-29E1-4720-A7DC-9F43751B56E7@oracle.com>
In-Reply-To: <6F0CCBAF-29E1-4720-A7DC-9F43751B56E7@oracle.com>
From: Olga Kornievskaia <aglo@umich.edu>
Date: Mon, 27 Nov 2023 11:42:08 -1000
Message-ID: <CAN-5tyGqSXyeu+LXWVu_J=A8CLW01c2wDKSfBeqFaaWLxnOAyw@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,

Given that rpc_gss_secreate() was written by you I hope you dont mind
questions. I believe gssd can't use the new api because it is
insufficient. Specifically, authgss_create_default() takes in a
structure which is populated with the correct (kerberos) credential we
need to be using for the gss context establishment.
rpc_gss_seccreate() sets the sec.cred =3D GSS_C_NO_CREDENTIAL. If you
believe I'm incorrect in my assessment that rpc_gss_secreate please
let me know.

As far as I can see, current libtirpc needs to be modified no matter
what. Perhaps there needs to be some config magic to demand the use of
higher version of libtirpc for the new code but it would be just a
different way an upstream nfs-utils won't build without an appropriate
libtirpc version. I would imagine distros would build matching
libtirpc and nfs-utils that would either both not have the fix or have
the fix.


On Wed, Nov 22, 2023 at 4:31=E2=80=AFAM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
> Possibly because authgss_create_default() was the API
> available to gssd back in the day. rpc_gss_seccreate(3t)
> is newer. That would be my guess.
>
>
> > On Nov 22, 2023, at 1:07=E2=80=AFAM, Olga Kornievskaia <aglo@umich.edu>=
 wrote:
> >
> > 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@or=
acle.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
> >>
> >>
> >>
>
> --
> Chuck Lever
>
>