Bug 2080449
Summary: | [Azure-file CSI Driver] Read/Write permission denied for non-admin user on azure file csi provisioned volume with fsType=ext4,ext3,ext2,xfs | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Rahul Deore <rdeore> |
Component: | Storage | Assignee: | Roman Bednář <rbednar> |
Storage sub component: | Operators | QA Contact: | Rahul Deore <rdeore> |
Status: | CLOSED ERRATA | Docs Contact: | |
Severity: | medium | ||
Priority: | medium | CC: | aos-bugs, jsafrane, rbednar, rdeore, stevsmit, wduan |
Version: | 4.11 | ||
Target Milestone: | --- | ||
Target Release: | 4.12.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Release Note | |
Doc Text: |
* Users can now opt into using the experimental VHD feature on Azure File. To opt in, users must specify the `fstype` parameter in a storage class and enable it with `--enable-vhd=true`. If `fstype` is used and the feature is not set to `true`, the volumes will fail to provision.
+
To opt out of using the VHD feature, remove the `fstype` parameter from your storage class. (link:https://bugzilla.redhat.com/show_bug.cgi?id=2080449[*BZ#2080449*])
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2023-01-17 19:48:18 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 2105972 |
Description
Rahul Deore
2022-04-29 16:25:48 UTC
Filed an upstream bug - https://github.com/kubernetes-sigs/azurefile-csi-driver/issues/1012 . This happens only for newly introduced VHD disk feature of azure file. VHD disks don't appear to be respecting fsgroup specified in the pods and hence non-admin pods can't write to the volume. We are not going to support VHD disks over azurefile CSI volumes. Support for VHD disks will either be disabled or prevented via webhook validation. So it seems there already is a patch upstream that fixes the issue: https://github.com/kubernetes-sigs/azurefile-csi-driver/pull/1013 Please test again with the latest upstream driver and close/verify this BZ if the bug can't be reproduced anymore. Tested on 4.11.0-0.nightly-2022-05-20-213928, but still failing with error as, ERROR: cannot create regular file '/mnt/storage/hello': Permission denied Hi @roman, just declare that QE will use the CSI Driver shipped with Openshift but not upstream one, current Azure-file CSI Driver version is 1.14.0 and looks like no plan to update to 1.18.0 in 4.11. So assign it back. Ack, it also turned out the upstream change did not address the bug as I thought, so I created a new one and trying to get it merged upstream. Then we can agree on a rebase or I'll do a cherry-pick. https://github.com/kubernetes-sigs/azurefile-csi-driver/pull/1023 Tested on 4.11.0-0.nightly-2022-06-21-040754, but scenarion is still failing for non-admin user, below are the observations, 1. When create pod as common-user (non-admin), neither admin nor common-user can write into the mounted pod volume (Permission denied for both admin and non-admin) sh-5.1$ id uid=1000670000(1000670000) gid=0(root) groups=0(root),1000670000 sh-5.1$ echo 'hello' > /mnt/azure/test.txt sh: /mnt/azure/test.txt: Permission denied sh-5.1$ sh-5.1$ 2. When create pod as Admin user, both Admin and common-user (non-admin) can write into the pod volume successfully sh-5.1# id uid=0(root) gid=0(root) groups=0(root) sh-5.1# sh-5.1# echo 'hello' > /mnt/azure/test.txt sh-5.1# cat /mnt/azure/test.txt hello sh-5.1# Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.12.0 bug fix and security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:7399 |