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:   Alan Maxwell <amaxwell@fedex.com>
To:     Benjamin Coddington <bcodding@redhat.com>
CC:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: RE: [EXTERNAL] nfsv4 client idmapper issue
Thread-Topic: [EXTERNAL] nfsv4 client idmapper issue
Thread-Index: AQHYzoyLB0ZCEFrXiEO+WVUdCpVZ7K3rfeBg
Date:   Thu, 22 Sep 2022 14:18:58 +0000
Message-ID: <DS0PR12MB648637C3D4E07C6FCA90A0E4C84E9@DS0PR12MB6486.namprd12.prod.outlook.com>
References: <DS0PR12MB6486987EC76AD88C7A80D229C84F9@DS0PR12MB6486.namprd12.prod.outlook.com>
 <46FAEBBD-50BC-464B-A983-1DC2232795C5@redhat.com>
 <DS0PR12MB6486B941F1EA96D2634CED63C84E9@DS0PR12MB6486.namprd12.prod.outlook.com>
 <812A1C59-B489-4D6B-8673-15F5C86A99D0@redhat.com>
In-Reply-To: <812A1C59-B489-4D6B-8673-15F5C86A99D0@redhat.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?k79jJ7Ru0NnDxEMETKuH223RjyvJn5uqbY1+7iFTcKgc/wu7izTK1fPMJT5E?=
 =?us-ascii?Q?N7e2GS04BilEljs+LR2KikAGHIYeMjGkjm7KyRHtgeZTOI/Z8GT68tpR2Olb?=
 =?us-ascii?Q?qWA0njb3Pp4YVafThsHZI8Gw2Wkfbyi8xW/JhQFjDk63jdfexPcOx3mblaNK?=
 =?us-ascii?Q?IZt+/Ncl7oTtdXv+5zBdz1OMcpFh7/0NeSfIfPxJNB+tuSa36dqJFQILqfHj?=
 =?us-ascii?Q?rP64Iy30XR3q6Hse7EhPgN1zoLJoLqDhL9+QRA7zwdpjgzw488gs5Y+obn3/?=
 =?us-ascii?Q?qATpAD8VooIb53PXRhbrcAPOZB08zLhmB/vqtZ13geutIUm32bHv0WL4LFWi?=
 =?us-ascii?Q?1zLQv6MNktp6fhW2LYP8Pt5bGP9FwouZMA9x1VRd2Lrbx8wg9XUQJg8wNJBZ?=
 =?us-ascii?Q?kedw5aUdp/ogP5ZPt8DXKtR5JFUweKkCm+joVIsBtB4L/rB9nR4h/U9zpt4P?=
 =?us-ascii?Q?oxoiC/Nvu0hdyIcRuZheWFOWVhHJ+gsvL/NJb1Kd13gCFsqjENMa5FnIegAV?=
 =?us-ascii?Q?pHGFUaRVB53BlmbZmYLwtZRsmMNw5dxNS0uPewXES4LeiXXq8lJz1VR5Y2eI?=
 =?us-ascii?Q?6yapMhqiWv6gMWZwr6Am60I3un279EwSD1sAJMTZm/i4aSlmleGXbhLsurgt?=
 =?us-ascii?Q?xZpwtux2xb6+mi6YOHTcHPzSgVh6/zHUakTm+u+DJsZ0e+HMsYTAS7syzCDF?=
 =?us-ascii?Q?s5ypiaxdFcWoxJ0phwO1+UmYNtNtiVW5eWFgB64Xw59fLD0QZUQpH2qWlQwM?=
 =?us-ascii?Q?pUlXzRy8dm087v2UfPymdfcsZkT083YFJJivx4U8gCyDWTOGYs9jpotkxiod?=
 =?us-ascii?Q?dnITO1slKkXr0CReu5Az5Pwhcyd3hBHrbat6rcNK4/sMtIkLx1A7oXVQgQjV?=
 =?us-ascii?Q?uK+Lswb7oje4BVb609yFW2JwEzl+GJj6yrNOe9/vvqY/AajXOsQA8Ql5TWI4?=
 =?us-ascii?Q?OpBmFE29StZYN05VSskiHhwQCCkAkT9xi5+WSxp9s0VgMG1z2vlOBPuIuFGl?=
 =?us-ascii?Q?lihqnUZ7rBILz1/HBWN2fGSbmuCCHOuWz7RryZEKoEJCZDb1G9HLaJRV5iDu?=
 =?us-ascii?Q?8naR+7IAhOXVr5FXDzxjtOL2Xj31RvB+AcyaNsaBo1fvAamD9Ur++voXzmmH?=
 =?us-ascii?Q?U1DGO7APbdVVHb/caQkAD8iv6jLx+0EZlElsLssqeTI6QR5VocGjs48A9uYC?=
 =?us-ascii?Q?qD5Rbol/x40l3X8kkr1wuuwU7U9RCR66SFq5FkPFE+dAtLClchYjIr1BQ1sd?=
 =?us-ascii?Q?IbPST+AJ0O/6Fyp5n2bTrdN10VMaI3ojA27wg7RKjXRe+DKBkfFa2JXdQuLU?=
 =?us-ascii?Q?f51W6NNdmVyrOcErkcKGm2JyOjETt3Wi2SeSxgRuzl1Ir1xB4V/TUe/0uDeC?=
 =?us-ascii?Q?K573MHonN1DCM4fGJMyFkSag8O3vejQcsreAN2ZEsQmT6Ky29DVsIQ3vft7t?=
 =?us-ascii?Q?s7kflrK50kUsHOPKGBHKGBc2LR8szJ68sOEIjompKueUlXbWLNOEuz/pY1EL?=
 =?us-ascii?Q?ARJiLIFiGh6HIfYYN4P7qmEYn1VrfYU5ZwOTMmxYegl0demLHOi+a1ZW2voJ?=
 =?us-ascii?Q?m980YDhOGjNo1LQhtZBgKIK6LJSsSEL3EAYSdGiM?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fedex.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DS0PR12MB6486.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 23c0180e-4d9e-444b-2ad1-08da9ca56397
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2022 14:18:58.0578
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b945c813-dce6-41f8-8457-5a12c2fe15bf
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: by1ARiBc+/69ATz+/6NbE0NpbXtOhjyJDSM/zhkRBfKqW6iOILZ3SWqlxPujA+nlTu+Uuz1D4XjFF6Rhou0PIQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB6884
X-Proofpoint-GUID: -cLiZYPJ7C-I1Nf8NfzfMpqZvfE9Eakv
X-Proofpoint-ORIG-GUID: -cLiZYPJ7C-I1Nf8NfzfMpqZvfE9Eakv
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-22_08,2022-09-22_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 bulkscore=0
 adultscore=0 impostorscore=0 malwarescore=0 phishscore=0 suspectscore=0
 clxscore=1015 mlxlogscore=966 mlxscore=0 spamscore=0 lowpriorityscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000
 definitions=main-2209220095
X-Spam-Status: No, score=-18.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,
        ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,
        USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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


-----Original Message-----
From: Benjamin Coddington <bcodding@redhat.com>=20
Sent: Thursday, September 22, 2022 9:06 AM
To: Alan Maxwell <amaxwell@fedex.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [EXTERNAL] nfsv4 client idmapper issue

On 22 Sep 2022, at 9:45, Alan Maxwell wrote:

> How would the server know what gidNumber to assign if the nfs client=20
> sent a name?

I'm not familiar with this server, but I'm guessing if you have it set to "=
Do not send names", then it also will try not to translate uid/gids it rece=
ives.  Are you asking a theoretical question?
We have server set to "do not send names" because our uid's are fully numer=
ic and that causes similar problem with nfs-client.

> Is there a method in Redhat to have the nfsclient only send=20
> uidNumbers/gidNumbers?

Better to use Red Hat's support for these type of questions because this li=
st is mostly upstream development work, but I believe that's the point of n=
fs4_disable_idmapping which exists on that kernel.
I have an open case with Redhat, they have instructed that, "the upstream k=
ernel has this feature, we can't make any corrections"


> Doing id mapping or better name , id verification, is expected. We=20
> hope the server would tell us, "client sent name I can't verify or lookup=
"

Right, and that is a signal to the client that the server is not doing the =
"Do not send names" thing, rather trying to map values, so the client chang=
es its behavior.

If you're only sending integer gid values, what does it mean to verify a gr=
oup id?  If you want your server to treat the values as integer gids, then =
it shouldn't return an error that means "I couldn't translate this into a g=
id".
Again, we would expect ultimately if the server returns error, nfs client s=
hould do same, show and error, not change the configuration and ignore our =
disable_id_mapping.

> The nfsclient  sends both a bad name and bad gidNumber, we actually=20
> think that should be the case, even and security=3Dsys , there should be=
=20
> validation of users and groups.

I'm sorry, I don't understand what you trying to say here.

Ben