Bug 1644421 - CephFS is creating exportable directories with 755 permission and causes containers not able to write on them using Manila
Summary: CephFS is creating exportable directories with 755 permission and causes cont...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat Storage
Component: CephFS
Version: 3.0
Hardware: All
OS: All
medium
low
Target Milestone: rc
: 3.2
Assignee: Patrick Donnelly
QA Contact: ceph-qe-bugs
URL:
Whiteboard:
Depends On:
Blocks: 1643167 1679273
TreeView+ depends on / blocked
 
Reported: 2018-10-30 19:28 UTC by Tom Barron
Modified: 2019-02-20 19:01 UTC (History)
8 users (show)

Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-03 19:02:13 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Ceph Project Bug Tracker 36651 0 None None None 2018-10-30 19:31:47 UTC
Github ceph ceph pull 24839 0 None closed ceph-volume-client: allow setting mode of CephFS volumes 2020-06-17 16:55:13 UTC
Red Hat Bugzilla 1643167 0 medium CLOSED CephFS is creating exportable directories with 755 permission and causes containers not able to write on them using Mani... 2022-07-09 13:58:04 UTC
Red Hat Product Errata RHBA-2019:0020 0 None None None 2019-01-03 19:02:22 UTC

Internal Links: 1643167 1679273

Description Tom Barron 2018-10-30 19:28:34 UTC
[Note, this for the ceph_volume_client side work required by the corresponding OpenStack BZ [1] - from which the following description is taken.

Description of problem:

Using manila-provisioner in OpenShift creates a manila share on OpenStack. When is mounted on the POD:

172.20.2.21:/volumes/_nogroup/0840a9cc-8936-4b25-8a45-3ff92d7a5f55   2097152       0   2097152   0% /test-manila

The permissions are the following

sh-4.2$ ls -ld /test-manila/
drwxr-xr-x. 1 nobody nobody 0 Oct 25 15:34 /test-manila/

The user executing the pod is the following:
sh-4.2$ id
uid=1000180000 gid=0(root) groups=0(root),1000180000


Version-Release number of selected component (if applicable):
rhceph-3-rhel7:3-11


How reproducible:


Steps to Reproduce:
1. Create a PVC on Openshift
2. Wait till PV is created
3. Add volume for the pod in the deployment config 

Actual results:
Pod is not able to write in the NFS share due to 755

Expected results:
Able to write in the share, a 775 or 2775


Additional info:
Another option it would be create the directory with nfsnobody and run the containers following OCP instructions for NFS: 
https://docs.openshift.com/container-platform/3.11/install_config/persistent_storage/persistent_storage_nfs.html#nfs-user-ids

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1643167

Comment 21 Tom Barron 2018-12-14 17:39:08 UTC
I have verified this bug as follows:

1) made a script that (A) creates shares, share-groups, shares in share groups, and snapshots of shares and of share groups via manila, and (B) mounts the backing CephFS file system and displays the permissions of the backing files.

2) ran the script with unmodified packages and verified that permissions are 755.

3) installed python-cephfs-12.2.8-51.el7cp.x86_64.rpm from the compose referenced above.

4) ran the script again without any changes to manila proper.
4.1 the script succeeded in creating and deleting the shares, share-groups, shares in share groups, and snapshots of shares and share groups.  So installing this rpm by itself causes no harm.
4.2 permissions are still 755 as one would expect

5) installed the manila-side changes from https://review.openstack.org/#/c/614332.  This is an install from git since it is a breaking change for manila until the ceph-side change is released.

6) ran the script again with no manila configuration changes.  Results were the same as 4.1 and 4.2, proving backwards compatible behavior.

7. Set the new ``cephfs_volume_mode`` config option to 775 and ran the script.
7.1 the script succeeded in creating all the expected objects.
7.2 permissions within the cephfs filesystem were set to 775 instead of 755 as desired.

Comment 23 errata-xmlrpc 2019-01-03 19:02:13 UTC
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, 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/RHBA-2019:0020


Note You need to log in before you can comment on or make changes to this bug.