On Tue, Dec 05, 2023 at 03:43:16PM -0500, Olga Kornievskaia wrote:
> On Mon, Nov 27, 2023 at 8:15 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
> >
> > On Mon, Nov 27, 2023 at 11:42:08AM -1000, Olga Kornievskaia wrote:
> > > 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 = GSS_C_NO_CREDENTIAL. If you
> > > believe I'm incorrect in my assessment that rpc_gss_secreate please
> > > let me know.
> >
> > Caller can pass its preferred credential in via the *req parameter
> > (parameter 6). Then rpc_gss_seccreate(3t) does this:
> >
> > 846 if (req) {
> > 847 sec.req_flags = req->req_flags;
> > 848 gd->time_req = req->time_req;
> > 849 sec.cred = req->my_cred;
> > 850 gd->icb = req->input_channel_bindings;
> > 851 }
> >
> > Wouldn't that work?
>
> Actually this does not work. However, this does:
> if (req) {
> sec.req_flags = req->req_flags;
> gd->time_req = req->time_req;
> gd->sec.cred = req->my_cred;
> gd->icb = req->input_channel_bindings;
> }
>
> Existing code is such that cred in gd->sec.cred is always null. I'm
> 100% certain of that but I can't explain why sec.cred=req->my_cred is
> not working. This is current code:
> in authgss_refresh()
> rpc_gss_sec:
> mechanism_OID: { 1 2 134 72 134 247 18 1 2 2 }
> qop: 0
> service: 1
> cred: (nil)
>
> Fixed libtirpc code as above (or code using authgss_create_default()):
> in authgss_refresh()
> rpc_gss_sec:
> mechanism_OID: { 1 2 134 72 134 247 18 1 2 2 }
> qop: 0
> service: 1
> cred: 0xffff9002e000
>
> If I were to fix the libtirpc this way, then I can use
> rpc_gss_seccreate from gssd and not use my previous changes. But it
> still requires changes to libtirpc. How is that not different from
> what's already there (as in committed)?
Very simple: The libtirpc implementation we use belongs to the Linux
community. The TI-RPC API that it implements does not; it's used in
several other OSes (including TI-RPC API implementations that appear
in other libraries on Linux), and it is publicly documented.
Thus we cannot alter the public structures and function synopses
unless all implementations do.
I need to audit the library code, but I think the direction of your
suggested fix to rpc_gss_seccreate(3t) is sensible.
--
Chuck Lever
