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] Re: nfsv4 client idmapper issue
Thread-Topic: [EXTERNAL] Re: nfsv4 client idmapper issue
Thread-Index: AdjN5dNv/53QmQ7mSiWe6weV81FGkQAkorMAAAQnwEA=
Date:   Thu, 22 Sep 2022 13:45:54 +0000
Message-ID: <DS0PR12MB6486B941F1EA96D2634CED63C84E9@DS0PR12MB6486.namprd12.prod.outlook.com>
References: <DS0PR12MB6486987EC76AD88C7A80D229C84F9@DS0PR12MB6486.namprd12.prod.outlook.com>
 <46FAEBBD-50BC-464B-A983-1DC2232795C5@redhat.com>
In-Reply-To: <46FAEBBD-50BC-464B-A983-1DC2232795C5@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?UyX3ABAphOJjsoCG4ggQBGv0ul61Z+YYET8TtxGZrJtBqYjlAQ3w5AmfJ2jk?=
 =?us-ascii?Q?DF1MfaZQXDoO1SKiW6/x7ZrvrDYhQFNBgH4CgCf6qZzUGUU894ewPXpsR0uU?=
 =?us-ascii?Q?NbHhRXdpT7r7Lev9ilT/ALBbAf4PpqRIWdwDY/K+M/8ieqqx4Bs8PVh8P+xz?=
 =?us-ascii?Q?bG98g3RyIH+XETPIXCSLcpMmA0H623/MUumSjFKM8TmkN5UpiSC0ltA+sFWH?=
 =?us-ascii?Q?WfGJSWjxZkXaP6RK/pU7RKxQXZDtLoa2DmI5baNiBTZUtOFXOT1WOULRTwe1?=
 =?us-ascii?Q?miSN3bHXC35Ap6J0X0PQrp0V9Ly0Xt/KV5JQChV4q/RV8l5KElNobz3fsVw0?=
 =?us-ascii?Q?w2hqvxsoFphQhSj99Ow5DHSXa2hQzFuu1CQc8pxv6OMW57VfPKco2ZCrYXpn?=
 =?us-ascii?Q?T2vF1NfJAHT/olffkpCv/OMSDTSLHZli0Lac7UGmGgbAh+Ce3/sxwuFxlpa1?=
 =?us-ascii?Q?syA3n+zV5DSJJcKJYbyg+2gLL8S73pBso5ihp/aKjowrYiehKPSZjyGfKnzA?=
 =?us-ascii?Q?ANyM6RXk2cXJSfK69bDL7XgoGUfv+a6/haABygV/GYkVSuZlwwOc8K+fBPwP?=
 =?us-ascii?Q?V6/z9MPlEu5QXVltAKnqPcb9OgRdrCN2y2+FK2yAnbaEl/Xd1UwwR5nA6ZEM?=
 =?us-ascii?Q?gDCO/aYw6ohF5GkqezImAN2qP+JiCeDidwM78S2hFOM33AKFxp1rnxzFVfc7?=
 =?us-ascii?Q?Vu53BzkFi8wqfKmccyF0EK3ehscKC3N6kBXdocfrtd9/asekdvsq//UBhwYJ?=
 =?us-ascii?Q?vf0FLh0tcpv75rmjTk4BRHaVmWNd94Zh23/4EEQmIkBL02vsgphHSVpNykO+?=
 =?us-ascii?Q?Zszbpa5WkvQQmBcVTKykjFz/Hbtv69ro9m2NpJ8Rh0nd1wUKGUlLdk22hk3t?=
 =?us-ascii?Q?/NG2MaDA2wOnu19flUjdZbgC12n45gBmdO3MaR3YsY4+FaKjL++Guc0vRMaR?=
 =?us-ascii?Q?L5LiVD7x4+D4YkfAyi/h5LUnoVPwkFGWfjN9Cxdxh9tvG2tg6VT0ZwPuu7Tj?=
 =?us-ascii?Q?b6MoThQ7GgsV4i8Aa/67h00jYZMgYLJav6kXH4jVvuo/ZB4BD48j1gbtJ2sU?=
 =?us-ascii?Q?ZUNG9RZi6uiwJFm5C4B+3LqmWeUJe1i0G1XL0vB4hqvqguFJ/RgyMbBpJ3jm?=
 =?us-ascii?Q?vV851/DbV+B5QCiKt8Vu37147OkXPHWBsYXJrKOL+7AqNRxz5gTWKS4abZAo?=
 =?us-ascii?Q?vX96EhIWr2PJdC6gH742+VT2WGaekLOHF9zN+AIp64ul1fbJzIkh0H7IKjB6?=
 =?us-ascii?Q?5+NjrfsQg9UJ7czIw44HbkdAeCEYHvPExgua8YPecd21CY9biL8SNal0/PXy?=
 =?us-ascii?Q?7V6IqxC86pUWrpnijGvyh2OfWH8qx1oWvLqDQ1UeFngSjc2fCBuzRSQ7Je2B?=
 =?us-ascii?Q?0Qotz6P0MCrigwHpwOJb+W0bxKnA80PqoOAL3Z+asQSI/AfAlPZYrtdvjthd?=
 =?us-ascii?Q?H8e8vVxxffXZ0wKesjKG7k0BTN2hYf/VFEblK4csANLxKbQhQmP1HZ83ag+w?=
 =?us-ascii?Q?O5LdZV3GnAwNEohKh/iaM08Kw9fDbgJGdh/U8B6KvD0c7FrlwmP4cW4aanEX?=
 =?us-ascii?Q?iYWcTh63gPBcX0b1fnCdBNVJqxSlKR3TB+57tRgG?=
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: 1cebc5ea-6567-4120-ffa1-08da9ca0c511
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2022 13:45:54.1181
 (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: LFLU+2UrwGOHSqnZUWrmjNxn0PzZQJQd4xNBIKxTh7KxskQ2xjAQtxEmPESSbm4lzLgjWNs40108MzALw6ugTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5373
X-Proofpoint-ORIG-GUID: xWTIgjeiMwXGdCk6wcfU48AJaAr5IEUI
X-Proofpoint-GUID: xWTIgjeiMwXGdCk6wcfU48AJaAr5IEUI
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 clxscore=1015 priorityscore=1501
 bulkscore=0 suspectscore=0 phishscore=0 adultscore=0 spamscore=0
 mlxscore=0 impostorscore=0 mlxlogscore=999 lowpriorityscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2209220091
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 6:42 AM
To: Alan Maxwell <amaxwell@fedex.com>
Cc: linux-nfs@vger.kernel.org
Subject: [EXTERNAL] Re: nfsv4 client idmapper issue

Caution! This email originated outside of FedEx. Please do not open attachm=
ents or click links from an unknown or suspicious origin.

On 21 Sep 2022, at 14:13, Alan Maxwell wrote:

> I am reporting an issue, not a fault or bugreport.
> NFS client : Redhat 7 kernel: 3.10.0-1160.71.1.el7.x86_64.
> The issue lies with the feature that nfs client that: if an nfs server=20
> rejects an unmapped uid or gid, then the client will automatically=20
> switch back to using the idmapper.
>
> Our particular configuration of nfsv4 server and client are based on=20
> using numeric uidNumber and gidNumber communication.  The nfs server=20
> we are using , OneFS (Dell/EMC/Isilon) has a setting explicitly for=20
> this use: "Do not send names".  We have this set and our testing=20
> showed working 100% with our nfs client.  The main driver for us using=20
> this feature is that our uid's are numeric.  That causes issues with=20
> commands like chown and apparently NFS setattr.  Once we realized=20
> that, we set the numeric setting and everything worked as planned.
> Our problem with the feature comes due to a  simple mistake made by an
> Admin:
>  chgrp groupnotvalid file
> When the admin issued a chgrp, but that group does not exist in the=20
> directory service for the NFS server, the NFS server rejected the=20
> change.  Then the feature kicked in that "client will automatically=20
> switch back to using the idmapper. " Which did make changes, the=20
> /proc/self/mountstats showing the caps=3D0x7fff instead of 0xffff.
> The only solution to get the mount to work as originally configured is=20
> to umount/mount the share.
> Bottom line: Our environment can not support idmapping.  Having the=20
> feature to disable it and that disable be forceful and not something=20
> the kernel can decide to re-enable.
> We would envision that if an invalid chown/chgrp were issued, to=20
> simply return an error, report that the chown/chgrp were not applied=20
> and simply leave the nfsmount as is.
>
> Alan Maxwell | Sr. System Programmer | Platinum Infrastructure|20=20
> FedEx Pkwy 1st Fl Vert,Collierville, TN 38017

Seems like a server bug to me -- if you want to set a numeric group on a fi=
le, the server doesn't need to "look up" the group to see if it exists, it =
should just set the value on the underlying filesystem.
How would the server know what gidNumber to assign if the nfs client sent a=
 name?
Is there a method in Redhat to have the nfsclient only send uidNumbers/gidN=
umbers?


What the server is signaling by sending back NFS4ERR_BADOWNER is that it ac=
tually /is/ doing id mapping.
Doing id mapping or better name , id verification, is expected. We hope the=
 server would tell us, "client sent name I can't verify or lookup"

Why doesn't OneFS just set the value when told "Do not send names"?
The nfsclient  sends both a bad name and bad gidNumber, we actually think t=
hat should be the case, even and security=3Dsys , there should be validatio=
n of users and groups.

Ben