Received-SPF: pass (google.com: domain of linux-nfs+bounces-353-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Tue, 5 Dec 2023 20:24:21 -0500
From: Chuck Lever <chuck.lever@oracle.com>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: Olga Kornievskaia <kolga@netapp.com>, Steve Dickson <SteveD@redhat.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: changes to struct rpc_gss_sec
Message-ID: <ZW/NRYp4IkWRORzo@tissot.1015granger.net>
References: <97AE695C-8F9F-4E9C-9460-427C284FBD32@oracle.com>
 <CAN-5tyHxvTevgM38q94W4e+rBzYu7tWqDHVMNcFQ5GT3uNArCw@mail.gmail.com>
 <6F0CCBAF-29E1-4720-A7DC-9F43751B56E7@oracle.com>
 <CAN-5tyGqSXyeu+LXWVu_J=A8CLW01c2wDKSfBeqFaaWLxnOAyw@mail.gmail.com>
 <ZWU/BvRX6BcnSQPj@tissot.1015granger.net>
 <CAN-5tyHi8app4K9aRj1paF=zG6PHLs3w8=C6iH4mZgduxvaAbA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAN-5tyHi8app4K9aRj1paF=zG6PHLs3w8=C6iH4mZgduxvaAbA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?eElQQzNVRDFlcGRtNWpaV1hDT0tOcFk1cTNqNzhUWWEvQ2l4dFdPeElKSVpk?=
 =?utf-8?B?UGxza0o3dHJwV2NxRU5tenJEVEtreHFKemkxbVIyQlFCYVpRdlFHZzQwUTJT?=
 =?utf-8?B?WGg0SkRHcjg3cVNsNlpGM0FOT3dhRTBhNy9rc3NteXVRNkJScEtVWE1XMkt6?=
 =?utf-8?B?ZHdhRGZzNkJlanRWclpoSVlOaTVoTkc0VUpOQy9yc3VDTTZENU1Xd2RXREpC?=
 =?utf-8?B?OVUxUy9SazlUV0VCSUVYQlFOTkZOeWoxa3k0SnBVR2cwWjJweTJndEJXcXZ4?=
 =?utf-8?B?UDNiNStGKzBWQkdYWDJyektaaXVSYlVaWktqUUdvZXpnblBWanJuM2xEdUlY?=
 =?utf-8?B?a3NWeTZBaEVjTkpIa25rZlplUEtRRjU5aFRNa29HeWpOaDAwaWg2WWpZMUE1?=
 =?utf-8?B?V1lDWjduZmxzUk9wd081SXUrRGtlRFZ1TCtxdGdFM3F1ekZUZjUrbG5lblBQ?=
 =?utf-8?B?WUNHNElDR2hnQmxzckZEM1NqNk5SeXo4clYveE4vYjJ0UHdPVFVhVUJKbHQ1?=
 =?utf-8?B?aWhHeVBmcm5vaEt0R3E5OUVjRlVxdjdWTjRTak1mWEZ1dXhVME5vYUxnT3ZV?=
 =?utf-8?B?NnJyT3RKcHJQcDN5VFR2VkhiMm1CUkd3M2ZyUHVYbDlIKzU1OVJSUEVrNzRQ?=
 =?utf-8?B?WVJwSGprWElmdHUyUTcyK3BnZmlFZ25sUFNvaHM3eW5ieWJYS0x3bHYvdkE2?=
 =?utf-8?B?ZUZvK0xyMmdpYTV0L2VGTVBVTXVCY29mQ3BFakUvcHJuVjV3KzgvaVlQcklh?=
 =?utf-8?B?azZVcjdhME92TVVHQWMwT2gyQXhISmVrRzg2U0sraHBwYXpxdzBEdDVKazJN?=
 =?utf-8?B?SFJMS0t5RnVHNC96SmxVUEd6S3hXY09IeUdOT2MrZDFwQ2tYNVpRVVBpRzMr?=
 =?utf-8?B?aCtieFU5RTBuOS8yZGZ1WEVoYzJKOEN1aUI3VTJ1ZEQrcnRwWXJlWEJMVER5?=
 =?utf-8?B?WGtUTnBxbDYyUTQ1dXRnSmMxSEtFalhkQkE0Q1hPUTM5TSs0TFRtWSs3UUVZ?=
 =?utf-8?B?ZU5EUUtmaS9PWHlDVUNDcmRYY2RnUHI3UGxwWW9wWE9GV09GUFNYZWVqVG1Y?=
 =?utf-8?B?bVptVTNFdW5DbVRuRWt0MEtQOFdaRkNFOVlrbTdOa0haRHRsQ2hYYkEveWVH?=
 =?utf-8?B?Ym5mMGpQZTlVNDJLN1l6V2ZETHk2UG53NStVY0tVb3NDNmRPKzFuMmJVdnpL?=
 =?utf-8?B?Q3VvdEw1Y2RYdWkyazVBTi96YjR0YTV4NnNZVitXVkxRdkxxQjJybTZ3d3cr?=
 =?utf-8?B?dFU4NVNpaTBTRzFFV1AxWTBPeFVmQTB4SGVzWnpNNDZ2WFc2cnNSYjhtRjUv?=
 =?utf-8?B?OHR5S3lqSXpONXNNTnVMU3JBeWU3b0VOcEh4alQzaWZmcTVXVC96MWVBczhK?=
 =?utf-8?B?ZWQ5Zk1tZUZhanI3bnRTelhLQVFDbGJQcnBBdjJXOER3V2JCZEE1V3RKa0ZD?=
 =?utf-8?B?V3gxa2gxVEV2cGNvTWVmaUk5bjIwT0l4WFNHdE12ZDlvcjAwWWZGaVBmS1E0?=
 =?utf-8?B?S2dwcXFzWHczNFh6RStnb0Z0YlppK3BDSnl2bFdSa0Q4bSsxalI4b2djRUhl?=
 =?utf-8?B?OFd6QmJSZkhhRkNBQjh6a25PNmJMNWs2R1l1WHdCMVJtQW1rYjRBVGlTcUhP?=
 =?utf-8?B?QTlJdGVQTzFYc3l3T1BCVXhUMDI2bU00bW1UMzdWU0pWdGxxNnczOWcrWTRS?=
 =?utf-8?B?U2N6WVdUR3AxNXB4ZUwxaElZNm1FSEZKajhwRUw5eU9UV2hVY1hGaCtQYVFX?=
 =?utf-8?B?cGJKaTg1aTUxdTE2OUd1NFUvdnVTbVlHUVB3TGNtNjF6UGtHKzltUXVIb0xi?=
 =?utf-8?B?ZG5tdThYYUVodS9ISzh2OElvY0h1cHFWT0ZEZmFDY1ZoRHIwbTlXc1BNdkRL?=
 =?utf-8?B?YldKRkYyNlJYSVFLNS9JZUJkSThVL2tnSDdEYlFyR0EzbG5LcE9PcGZERmZ0?=
 =?utf-8?B?SUtSbUFCOFBYTlVPM2w3TFZNU1ZreDVyVmI4QStTZHdKQmxUT3NFVEZsRDMw?=
 =?utf-8?B?V1pwQWxNaGF6QmlxZjd2aGpiUWozVUtjTHd4Vmo5ZUtML0k3eU5lQjlTZ2NC?=
 =?utf-8?B?S0UwRVdFY29hbysvU0E0YlpmWmNxczhkUkxueDNmWXQ3Z2oxN3RiTStaUDc3?=
 =?utf-8?B?cHFJMlNxNWdOSjU3NjhlTlZaZFVPWHhOdEIvSDNjamIzUTdUUmxpaDZUTHZZ?=
 =?utf-8?B?aFE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	TJxdLWLBeVs0ZHF85wW3r2Vc9xiAl06gl1JLNZj4vFvrcZJcxStGeXRoUCQlJlCghjfkpTyN92yW/IBU4mYB902qX6mhHJxo3hFjLWobu0kSPcDjZQTai172zCANWR5u3K94bW819BaIPOd+6OfAE8fngs11avr6LANqpYRp7jE+cKCwOFFCMy64THaBI+BK570c/TaupZQHoiHPdNWQI+w+7ow8POHupjHB32xihy7xMq0pVT33NTwQ0x7OY4C0toMNAs51vdSXRCyc66hAjHPYqY4O5X2PVpPM0+9cj/IriUYMD+9oRPji/z+lxUkv60Zm8WrlSQeI1EcYpbtX6fWBJ/vTMkxLPUJuSiWRCUAarX2ijQKy5xrn+FvBA3MhFK8Qcz5AmfOUG/4UwKyIiUHUSq31rUCquJxmJar4trWImpOa8tf/zm5RVvU1zCxvGGpIDfCPbUUpf0nICKBu6vwKgidmvEKD7CX55nRI/b3F93jUjZtiupqxdxJQx4+xJ/oInb4NLR8cAVDHboPqql3m/J49WcVVynK5dceinGXXViqlQJXS9mOVc5OPGtuMQjmE2BoNcUFOVnOGpp38CX5lFsC/qa8GeYqwGXQLlA4hP+B0P0I4bO1VVCHNcFyOC1JOGc2wXaP7ElL6Q9O9uX2nZiqQK27fuG40G8fHUD5QPzAbHp5eA0fL2m1zhIGcvltbcCCJ/9skmCZqXPNRE50fezaOVLHb2OVU/yjN5Vo3yFDEAXI+Aj8WNlWqQ1YbgHDGx7pCZhAip0BwwqmXitfUoGwQrgYRHCIKfz1BNvXWjyu4qJUkGhZ4cU32hn0Z3zC0+2eS9augEsEnnQ95fd8gok4/cC+Da9M4DxxhCz0=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 51d875f4-38a3-4833-b77e-08dbf5fa1495
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2023 01:24:24.1174
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gXKjf5ZTTMRpOIrfkMk5ZB7LSkBLSyexKCwZWqf9o6qseO+JhNxaxU3AEbapr5B8YZb0j1wl8jaQtRR2Al4vcQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB5883
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2023-12-06_01,2023-12-05_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0
 mlxscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000
 definitions=main-2312060010
X-Proofpoint-ORIG-GUID: og7yE7kWZzlv6xq30wsZFS0g70n7W2WT
X-Proofpoint-GUID: og7yE7kWZzlv6xq30wsZFS0g70n7W2WT

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@oracle.com> 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