Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: NFSv4.0 callback with Kerberos not working
Thread-Topic: NFSv4.0 callback with Kerberos not working
Thread-Index: AQHYzDztMjvFTe1YQk+Xo2ZaIaryZK3nCq2AgAAEdwCAAXtRgA==
Date:   Tue, 20 Sep 2022 16:53:12 +0000
Message-ID: <64CAE713-4853-40F6-9DE7-09730C87E145@oracle.com>
References: <BE5B3B9F-53EF-49E4-9734-CF89936D5F2C@oracle.com>
 <4e79b32842427aa92bf62c5c645430bd23b413e4.camel@hammerspace.com>
 <1BEBDDFF-EB65-47E4-83F4-DA2F680B940E@oracle.com>
In-Reply-To: <1BEBDDFF-EB65-47E4-83F4-DA2F680B940E@oracle.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ry4jZVUzMy08e7nurnwIUvjC15BnGVPf6yQq8q3im1B4OeNPxFEjafgImFRW?=
 =?us-ascii?Q?DvcLCuZ/a/p7cPbJFT6LLQRZYo0uhuDBz5y24HKqsl2T11jTZB+9fv7yhWRY?=
 =?us-ascii?Q?vOTN6XRNECdtOkKAv1Q3dkhJbDqIWyDKuu/xpMpIrOJg6oObyQIHdarB4vyp?=
 =?us-ascii?Q?9Vl1hWtFPKk+uUnnjjgB/Rpq8HVUPTfCC5fGpGGZUTWOuGcKUjo28auxsH60?=
 =?us-ascii?Q?LHnywJ0qHnupboQWkKH23GQkLknmjOqGx7dUARiZDYH85TaUHGOaalegBKWq?=
 =?us-ascii?Q?SNjuNZ12j8reqVZKdEIxYTvYW4RvZ5vTNSe8+88kvg4liKBGkmhjzpwfj5Le?=
 =?us-ascii?Q?BlK0/Hu5FP6Xq0LpyRJEB2g09067pSOJhw9bhos3as1ZlZS+rPxS1/ftEIsk?=
 =?us-ascii?Q?cxdpWx27VEPFyVCW6TUBjPtjON3thsCXQkMV+B12aHUfJ4SwuX9jRM8pV05M?=
 =?us-ascii?Q?Al4x5mPPWleJZJKX1HoyzcIWW5XSi4F16smBToVcD1Lh3sNPDQH7cxxliYAD?=
 =?us-ascii?Q?nmP4PP1H31KnAvuRoMiKEqbS3YyN7IzUSQaKb8sLxRoXmH5kHXyK6vHcFid1?=
 =?us-ascii?Q?ga8w0Up511x+zvI5LEU+XVMVmc/XmaPWA5Oc5HP0rd9//7r2Dn4+ex+hRw6m?=
 =?us-ascii?Q?NV+XXEpBm8dWqblDlTnSvy2F2W9dQslJ3btankb0XVpbKSY8qsbyHnVs8HQ9?=
 =?us-ascii?Q?VpcxcjfNL0OdJ/S9W7qwOeuj9gafT7PFWzKs5B6mDBAcazKFLBp9BjJhFm6p?=
 =?us-ascii?Q?LxKviwl+MEG2hoTqXJ1k1/lc/H/qmOuWMYPDfCOtBf80Z3y2VKxQi5s5v0U1?=
 =?us-ascii?Q?xr7fLWt+Eq7p0rSguHFVJQw4CRd8c0OUbLAQoP3amP7bG/mxziC3J39jAmc2?=
 =?us-ascii?Q?uSD9ZVAgYOGOF/sZeAe9tFeNNrJPN3WWwXFX4gKkvJ2n1+Xsv2/NHBoRug11?=
 =?us-ascii?Q?6ldye6SdASot36T8lT9CdI1yJRKb8EtY8MEg0WG9W18WPJLUko86cYEGeMoa?=
 =?us-ascii?Q?ZjxlRZqrlSJRYEGVo05gec0Gb6Lgh1ipfccf3GtA4LR6FTWzxto8CgnJrnf6?=
 =?us-ascii?Q?8V0kJ8w0ykXTE92S7K4hL6HQ4V+F24OzW2crLEYPsP8DvhmhMorxfaxrNIBb?=
 =?us-ascii?Q?uGT3P+mNDJb8lS/HLJAQ1MIZGb093wKh3x9t6wmAVi5xnpaSYykk1phkyUy2?=
 =?us-ascii?Q?ZaQfmEgukE+9ETw/lAXBxgAtks8DAEn81Ui6Mqud8tR9M24b+cJ56R35ozr4?=
 =?us-ascii?Q?uNcKdZNBY3buqY8LsZg1itgfnLs08xONXH/M+JdwpcPV47gd5OZGWs2D/Xzp?=
 =?us-ascii?Q?tIAPXDaSntVAZ/8YOFWIOZNxyg4HHl5Avraaa/0omxmRoadjnxjhnQkZlPj8?=
 =?us-ascii?Q?NuiYqc9oNAIZeSOsgrxlvb7So13sByhbZlrEXk/Cl8M7/GVtmC0OSHC6Cpc0?=
 =?us-ascii?Q?seYJuJlsFFZuB/8dGi1LD0/BwdIvC0El1fKylb9iqi32TyYNnNyPVBQMqOe8?=
 =?us-ascii?Q?j1MnFX9UiiCWvSmagnt/0FRAe6wPrmySbEe+VkPUt/RdhDcSzDjuASV+8BO/?=
 =?us-ascii?Q?79cmZsiBg/QV2hnj/6c7yOLzKugI00isEIj2BsvDOWwwsdJHMowP1x24pQk8?=
 =?us-ascii?Q?tQ=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <37A04EAD6B57284BA718AA55EEF4EC54@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95e73f99-ae56-4a9d-e4a3-08da9b289acc
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2022 16:53:12.3994
 (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: OIhhCYYl/ZZmMhFqalZKunwPTJ8smQDi72cdLBDwiqtE8LfwLCYisy/2FbQxIb3m/NrEqcopyJUuyQLAcPtgAA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5331
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.528,FMLib:17.11.122.1
 definitions=2022-09-20_07,2022-09-20_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=946 adultscore=0
 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2209200100
X-Proofpoint-ORIG-GUID: T99vaRRGdXpa5pjVCorp3m0MFwfIAzD-
X-Proofpoint-GUID: T99vaRRGdXpa5pjVCorp3m0MFwfIAzD-
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Sep 19, 2022, at 2:15 PM, Chuck Lever III <chuck.lever@oracle.com> wro=
te:
>=20
>> On Sep 19, 2022, at 1:59 PM, Trond Myklebust <trondmy@hammerspace.com> w=
rote:
>=20
>> The same principal is also used by the NFSv4 server to identify itself
>> when acting as a client to the NFS callback service according to
>> RFC7530 section 3.3.3.
>> So what I'm saying is that for the standard NFS client, then '*' is
>> probably the right thing to use (with a slight preference for 'host/'),
>> but for the NFS server use case of connecting to the callback service,
>> it should specify the 'nfs/' prefix. It can do that right now by
>> setting the clnt->cl_principal. As far as I can tell, the current
>> behaviour in knfsd is to set it to the same prefix as the server
>> svc_cred, and to default to 'nfs/' if the server svc_cred doesn't have
>> such a prefix.
>=20
> The server uses the client-provided service name in this case.
> If the client authenticates as "host@" then the server will
> authenticate to the "host@" service on the backchannel.
>=20
> Maybe the only mismatch is that my server is using
> "host@client.ib.example.net" on the backchannel, and it should
> be using "host@client.example.net" instead?

The Linux NFS server uses gssproxy to acquire a credential for
the NFS4_CB context. It appears to be using "uname -n" instead
of the hostname bound to its InfiniBand network interface --
the latter is what matches the acceptor in the context
established by SETCLIENTID, and the former does not.

I've filed an issue against gssproxy to get help understanding
what's going wrong:

https://github.com/gssapi/gssproxy/issues/65


--
Chuck Lever