Bug 1028465 - non-root user not allowed to rename the directory
non-root user not allowed to rename the directory
Status: CLOSED NOTABUG
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterd (Show other bugs)
2.1
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: krishnan parthasarathi
Sudhir D
: ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-08 09:10 EST by Saurabh
Modified: 2016-01-19 01:15 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-13 06:57:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Saurabh 2013-11-08 09:10:23 EST
Description of problem:
As non root user rename of directory is not getting allowed

There are two scenarios here, 

1. when the directory inside mount-point, say "dir" is given non-root user(say qa1) permissions, is tried to be renamed fails with "Permission Denied". 

2. when the sub-directory(say subdir) inside the above created "dir" exists, Also the "dir" quota space is full and we try rename the subdir, after increasing the quota limit for "dir".  rename fails with "Disk quota exceeded"

Given the fact that I am logged in as qa1(non-root user).

These issues are seen with both nfs and glusterfs mount.


Version-Release number of selected component (if applicable):
glusterfs-3.4.0.40rhs-1

How reproducible:
always

Steps to Reproduce:
1. have volume of 6x2 config, enable quota and set limit
2. mount over nfs or glusterfs
3. create a dir, chown the dir to a non-root user. 
4. set some limit on the dir
5. create a subdir inside the dir, fill data in the subdir, till limit is reached. 
6. now increase the quota limit for dir to a higher value.
7. try to rename dir
8. try to rename dir/subdir

execute steps 5, 7, 8 after logged into system as non-root user.

Actual results:

[qa1@rhslong03 nfs-test-dist-rep1]$ mount | grep nfs-test-dist-rep1
10.70.35.188:dist-rep1 on /mnt/nfs-test-dist-rep1 type nfs (rw,addr=10.70.35.188)

first scenario,
[qa1@rhslong03 nfs-test-dist-rep1]$ ls -ld qa1-rename/
drwxr-xr-x. 3 qa1 qa 96 Nov  6 17:07 qa1-rename/
[qa1@rhslong03 nfs-test-dist-rep1]$ mv qa1-rename/ qa1
mv: cannot move `qa1-rename/' to `qa1': Permission denied

second scenario,
[qa1@rhslong03 qa1-rename]$ pwd
/mnt/nfs-test-dist-rep1/qa1-rename
[qa1@rhslong03 qa1-rename]$ ls -ld dir
drwxr-xr-x. 2 qa1 qa 49152 Nov  8 19:32 dir
[qa1@rhslong03 qa1-rename]$ mv dir dir-rename
mv: cannot move `dir' to `dir-rename': Disk quota exceeded

whereas if you see I have lot of space left, 
[root@quota5 ~]# gluster volume quota dist-rep1 list
                  Path                   Hard-limit Soft-limit   Used  Available
--------------------------------------------------------------------------------
/                                          1.0TB       80%     377.4GB 646.6GB
/qa1-rename                              300.0GB       80%     224.1GB  75.9GB



Expected results:
rename in these cases should be allowed

Additional info:
 
Volume Name: dist-rep1
Type: Distributed-Replicate
Volume ID: be61bc6e-3140-468b-899d-430c1935441d
Status: Started
Number of Bricks: 6 x 2 = 12
Transport-type: tcp
Bricks:
Brick1: 10.70.35.188:/rhs/brick2/d1r11
Brick2: 10.70.35.108:/rhs/brick2/d1r21
Brick3: 10.70.35.191:/rhs/brick2/d2r11
Brick4: 10.70.35.144:/rhs/brick2/d2r21
Brick5: 10.70.35.188:/rhs/brick2/d3r11
Brick6: 10.70.35.108:/rhs/brick2/d3r21
Brick7: 10.70.35.191:/rhs/brick2/d4r11
Brick8: 10.70.35.144:/rhs/brick2/d4r21
Brick9: 10.70.35.188:/rhs/brick2/d5r11
Brick10: 10.70.35.108:/rhs/brick2/d5r21
Brick11: 10.70.35.191:/rhs/brick2/d6r11
Brick12: 10.70.35.144:/rhs/brick2/d6r21
Options Reconfigured:
features.quota: on
features.quota-deem-statfs: on
Comment 1 Saurabh 2013-11-08 09:23:16 EST
It is happening even without in quota in consideration

[root@rhslong03 nfs-test-dist-rep1]# mkdir dir6
[root@rhslong03 nfs-test-dist-rep1]# chwon qa1:qa dir6
bash: chwon: command not found
[root@rhslong03 nfs-test-dist-rep1]# chown qa1:qa dir6
[root@rhslong03 nfs-test-dist-rep1]# ls -l dir6
total 0
[root@rhslong03 nfs-test-dist-rep1]# ls -ld dir6
drwxr-xr-x. 2 qa1 qa 36 Nov  8  2013 dir6
[root@rhslong03 nfs-test-dist-rep1]# 
[root@rhslong03 nfs-test-dist-rep1]# su qa1
[qa1@rhslong03 nfs-test-dist-rep1]$ mv dir6 dir6-rename
Comment 3 Saurabh 2013-11-12 06:45:48 EST
as per discussion with developer, here are the observations,

glusterfs-nfs mount-point permissions,
[root@rhsauto005 ~]# ls -ld /mnt/nfs-test-213/
drwxr-xr-x. 14 root root 49152 Nov 12 03:45 /mnt/nfs-test-213/


kernel-nfs mount-point permissions,
[root@rhsauto005 ~]# ls -ld /opt
drwxrwxrwx. 6 root root 4096 Nov 12 06:27 /opt


rename operations on kernel-nfs mount-point, directory in consideration is "dir"

[qa1@rhsauto005 nfs-test-213]$ ls -l /opt
total 16
drwxr-xr-x. 2 qa1  qa1  4096 Nov 12 06:26 dir
drwxrwxrwx. 5 1000 1000 4096 May 25  2012 qa
drwxr-xr-x. 2 test test 4096 Nov  8 08:38 qa1
drwxr-xr-x. 2 root root 4096 Jun 21 04:05 rh
[qa1@rhsauto005 nfs-test-213]$ mv /opt/dir /opt/dir-rename
[qa1@rhsauto005 nfs-test-213]$ ls -l /opt
total 16
drwxr-xr-x. 2 qa1  qa1  4096 Nov 12 06:26 dir-rename
drwxrwxrwx. 5 1000 1000 4096 May 25  2012 qa
drwxr-xr-x. 2 test test 4096 Nov  8 08:38 qa1
drwxr-xr-x. 2 root root 4096 Jun 21 04:05 rh
Comment 6 santosh pradhan 2013-11-12 23:24:47 EST
Couple of  basic questions:

1. Does it happen only when Quota is enabled or without quota as well?

2. What is the behaviour with native/FUSE mount? i.e. Does the issue only seen in Gluster NFS?
Comment 7 santosh pradhan 2013-11-12 23:29:29 EST
(In reply to Susant Kumar Palai from comment #4)
> Currently the glusterfs root inode is getting the permission  755. Hence,
> from  as the non root user doesn't have  write permission on the directory
> created by root, it will  not be able to rename this directory ( EPERM
> ERROR) even though it is  made owner of that directory, which is an obvious
> behaviour .

When the non-root user is made owner, it got the write permission (in user-group-other sequence), so rename() should not FAIL ideally.

If the issue is consistent with FUSE, then mostly the problem is in DHT or so.

By the way, what does log say?
Comment 8 Susant Kumar Palai 2013-11-13 01:31:39 EST
(In reply to santosh pradhan from comment #6)
> Couple of  basic questions:
> 
> 1. Does it happen only when Quota is enabled or without quota as well?
> 
> 2. What is the behaviour with native/FUSE mount? i.e. Does the issue only
> seen in Gluster NFS?

It happens even with quota disabled. And the the behaviour is same for native/FUSE mount as well.
Comment 9 Susant Kumar Palai 2013-11-13 01:35:22 EST
modifying my 1st comment as there was a typo.

Currently the glusterfs root inode is getting the permission  755. Hence, as the non root user doesn't have  write permission on parent of the directory which is root ('/'), it will  not be able to rename this directory ( EPERM ERROR) even though it is  made owner of that directory, which is an obvious behaviour . But it can do all the operations inside that directory.

    I checked with samba and the behaviour is same as glusterfs mount .  The exception is kernel nfs, where its root inode is getting 777 permission and hence,  the rename operation is feasible there (as any non root user will inherit the write permission).

So as of now the above behaviour is a obvious one from Glusterfs point of view.
Comment 10 Saurabh 2013-11-13 03:53:25 EST
Thanks to Santoch and Rajesh for providing there inputs.
So, presently as per the trials we did for mount of different directories, it is found that kernel-nfs mount exports the same permissions as they are found for the "directory in consideration" on the server node. 

Whereas for Glusterfs volume mount, we still are doing a mount with permissions as 755.

Also, for a subdirectory mount in a glusterfs volume also behaves the same as mentioned for kernel-nfs mount.
Comment 11 santosh pradhan 2013-11-13 04:42:46 EST
mount command/protocol(NFS) just fetches the permissions set at the backend directory and modify the same for mount point at client end. Does not do anything more than that. :) 

Difference between Gluster NFS/FUSE and Kernel NFS:

For Gluster, volume is not just a single directory but a set of directories distributed across the bunch of the machines (called as bricks). If the client wants a mount with 777 permission, there can be workaround(s):

1) all the directories in all the bricks has to be chmod'd to 777 and restart the Gluster daemons. :) 

OR

2) Create a subdir with 777 permission and mount it.

Why volume gets exported with 755 permission:
As its a distributed arch, the directory has to be created in all the brick m/cs, and mkdir() considers umask() while creating directory. Permission ll be set accordingly. 

Having said all these, This does not look like a DEFECT. Can we close it ? :)
Comment 12 Saurabh 2013-11-13 06:57:03 EST
based on comment#10 and comment#11 closing this issue

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