chown on a file with 777 permission does not work for any non-root user, not even the owner of the file
I have NFSv3 mount on linux client and trying to change the owner of the file: [root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error : 2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user) if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; } So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here: 2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check) if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; } if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; } access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs. Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files. Frank
Frank, Thanks for the reply. I got your point. Most of the enterprise NFS servers provide a hook to allow chown by non root users. Can we implement a hook which when set allow NFSv3 setattr by non root to change owner of the file when file has write permission. ACLs are anyway a solution with NFSv4. regards, Deepthi On 11 Mar 2020 19:55, Frank Filz <ffilzlnx@mindspring.com> wrote:
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs. Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files. Frank
Is there some documentation on how this works on other servers you can point us to? I wasn't aware this was allowed outside the context of ACLs, though obviously if you can allow the action with ACLs, there might be a case for allowing it otherwise, though ACLs allow it on a per-file basis (and Windows only allows an administrator to set "take ownership" flag on a file so the user can take ownership of a file as opposed to the administrator changing the ownership). Frank From: Deepthi Shivaramu [mailto:des@vmware.com] Sent: Wednesday, March 11, 2020 8:08 AM To: Frank Filz <ffilzlnx@mindspring.com>; devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file Frank, Thanks for the reply. I got your point. Most of the enterprise NFS servers provide a hook to allow chown by non root users. Can we implement a hook which when set allow NFSv3 setattr by non root to change owner of the file when file has write permission. ACLs are anyway a solution with NFSv4. regards, Deepthi On 11 Mar 2020 19:55, Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com> > wrote:
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of 'new.txt': Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of 'new.txt': Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs. Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files. Frank
Netapp does it by using a filer level flag which when set to off on server will let non root users to do chown. Needs some hook in code where we decide to fail the op now, to check for this new flag and allow. https://kb.netapp.com/app/answers/answer_view/a_id/1036166/~/how-to-configur... On 11 Mar 2020 22:14, Frank Filz <ffilzlnx@mindspring.com> wrote: Is there some documentation on how this works on other servers you can point us to? I wasn’t aware this was allowed outside the context of ACLs, though obviously if you can allow the action with ACLs, there might be a case for allowing it otherwise, though ACLs allow it on a per-file basis (and Windows only allows an administrator to set “take ownership” flag on a file so the user can take ownership of a file as opposed to the administrator changing the ownership). Frank From: Deepthi Shivaramu [mailto:des@vmware.com] Sent: Wednesday, March 11, 2020 8:08 AM To: Frank Filz <ffilzlnx@mindspring.com>; devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file Frank, Thanks for the reply. I got your point. Most of the enterprise NFS servers provide a hook to allow chown by non root users. Can we implement a hook which when set allow NFSv3 setattr by non root to change owner of the file when file has write permission. ACLs are anyway a solution with NFSv4. regards, Deepthi On 11 Mar 2020 19:55, Frank Filz <ffilzlnx@mindspring.com<mailto:ffilzlnx@mindspring.com>> wrote:
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs. Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files. Frank
I'm not sure we *can* do this... We're not doing the actual chown, the backing filesystem is. VFS won't let you do this, and I don't think any of the clustered FSs will. Maybe RGW, but I'm not sure how users work there. Daniel On Wed, Mar 11, 2020 at 1:48 PM Deepthi Shivaramu <des@vmware.com> wrote:
Netapp does it by using a filer level flag which when set to off on server will let non root users to do chown. Needs some hook in code where we decide to fail the op now, to check for this new flag and allow.
https://kb.netapp.com/app/answers/answer_view/a_id/1036166/~/how-to-configur...
On 11 Mar 2020 22:14, Frank Filz <ffilzlnx@mindspring.com> wrote:
Is there some documentation on how this works on other servers you can point us to? I wasn’t aware this was allowed outside the context of ACLs, though obviously if you can allow the action with ACLs, there might be a case for allowing it otherwise, though ACLs allow it on a per-file basis (and Windows only allows an administrator to set “take ownership” flag on a file so the user can take ownership of a file as opposed to the administrator changing the ownership).
Frank
From: Deepthi Shivaramu [mailto:des@vmware.com] Sent: Wednesday, March 11, 2020 8:08 AM To: Frank Filz <ffilzlnx@mindspring.com>; devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file
Frank,
Thanks for the reply. I got your point.
Most of the enterprise NFS servers provide a hook to allow chown by non root users. Can we implement a hook which when set allow NFSv3 setattr by non root to change owner of the file when file has write permission. ACLs are anyway a solution with NFSv4.
regards,
Deepthi
On 11 Mar 2020 19:55, Frank Filz <ffilzlnx@mindspring.com> wrote:
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs.
Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files.
Frank
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
We also have a way of achieving this in ganesha with the help of “is_superuser” FSAL API. - Sriram From: Frank Filz <ffilzlnx@mindspring.com> Date: Wednesday, March 11, 2020 at 9:45 AM To: Deepthi Shivaramu <des@vmware.com>, "devel@lists.nfs-ganesha.org" <devel@lists.nfs-ganesha.org> Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file Is there some documentation on how this works on other servers you can point us to? I wasn’t aware this was allowed outside the context of ACLs, though obviously if you can allow the action with ACLs, there might be a case for allowing it otherwise, though ACLs allow it on a per-file basis (and Windows only allows an administrator to set “take ownership” flag on a file so the user can take ownership of a file as opposed to the administrator changing the ownership). Frank From: Deepthi Shivaramu [mailto:des@vmware.com] Sent: Wednesday, March 11, 2020 8:08 AM To: Frank Filz <ffilzlnx@mindspring.com>; devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file Frank, Thanks for the reply. I got your point. Most of the enterprise NFS servers provide a hook to allow chown by non root users. Can we implement a hook which when set allow NFSv3 setattr by non root to change owner of the file when file has write permission. ACLs are anyway a solution with NFSv4. regards, Deepthi On 11 Mar 2020 19:55, Frank Filz <ffilzlnx@mindspring.com<mailto:ffilzlnx@mindspring.com>> wrote:
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs. Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files. Frank
However, with is_superuser it does not grant any file owner to change the ownership. Only a few users can be given a superuser role according to FSAL implementation. - Sriram From: Sriram Patil <sriramp@vmware.com> Date: Wednesday, March 11, 2020 at 11:40 AM To: Frank Filz <ffilzlnx@mindspring.com>, Deepthi Shivaramu <des@vmware.com>, "devel@lists.nfs-ganesha.org" <devel@lists.nfs-ganesha.org> Subject: Re: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file We also have a way of achieving this in ganesha with the help of “is_superuser” FSAL API. - Sriram From: Frank Filz <ffilzlnx@mindspring.com> Date: Wednesday, March 11, 2020 at 9:45 AM To: Deepthi Shivaramu <des@vmware.com>, "devel@lists.nfs-ganesha.org" <devel@lists.nfs-ganesha.org> Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file Is there some documentation on how this works on other servers you can point us to? I wasn’t aware this was allowed outside the context of ACLs, though obviously if you can allow the action with ACLs, there might be a case for allowing it otherwise, though ACLs allow it on a per-file basis (and Windows only allows an administrator to set “take ownership” flag on a file so the user can take ownership of a file as opposed to the administrator changing the ownership). Frank From: Deepthi Shivaramu [mailto:des@vmware.com] Sent: Wednesday, March 11, 2020 8:08 AM To: Frank Filz <ffilzlnx@mindspring.com>; devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: chown on a file with 777 permission does not work for any non-root user, not even the owner of the file Frank, Thanks for the reply. I got your point. Most of the enterprise NFS servers provide a hook to allow chown by non root users. Can we implement a hook which when set allow NFSv3 setattr by non root to change owner of the file when file has write permission. ACLs are anyway a solution with NFSv4. regards, Deepthi On 11 Mar 2020 19:55, Frank Filz <ffilzlnx@mindspring.com<mailto:ffilzlnx@mindspring.com>> wrote:
I have NFSv3 mount on linux client and trying to change the owner of the file:
[root@sc-rdops-vm07-dhcp-212-202 mnt]# ls -la new.txt -rwxrwxrwx. 1 testu2 testg2 7 Mar 11 04:00 new.txt [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu2 [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=2222(testu2) gid=8888(testg2) groups=8888(testg2) [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu2@sc-rdops-vm07-dhcp-212-202 mnt]$ [root@sc-rdops-vm07-dhcp-212-202 mnt]# su testu1 [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ id uid=1111(testu1) gid=8888(testg2) groups=8888(testg2) [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$ chown testu1 new.txt chown: changing ownership of ‘new.txt’: Operation not permitted [testu1@sc-rdops-vm07-dhcp-212-202 mnt]$
The file belongs to testu2 and when I try to change the owner to testu1 logged in as testu2, it hits this error :
2020-03-11T11:12:08Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_46] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (new OWNER was not user)
if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */ . <--- It says owner of file cannot change the ownership to someone else. Someone else needs to take ownership. if (attr->owner != creds->caller_uid) { status = fsalstat(ERR_FSAL_PERM, 0); note = " (new OWNER was not user)"; goto out; }
So I login as non-owner, testu1 and try chown, it proceeds from this check but fails here:
2020-03-11T11:11:01Z : epoch 5e5f8af3 : vdfsops0aa0d27c.vsanfs-sh.prv : ganesha.nfsd-50332[::ffff:10.160.212.202] [svc_41] 354 :fsal_check_setattr_perms :FSAL :Access check returned Forbidden action (no ACL to check)
if (current->acl) { status = obj->obj_ops->test_access(obj, access_check, NULL, NULL, false); note = " (checked ACL)"; goto out; }
if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) { /* Without an ACL, this user is not allowed some operation */ status = fsalstat(ERR_FSAL_PERM, 0); note = " (no ACL to check)"; goto out; }
access_check variable starts with 0 and we put in only FSAL_ACE_PERM_WRITE_OWNER in first block for chown case. So obviously it does not contain FSAL_ACE_PERM_WRITE_DATA which we are checking here. So how do we expect this to proceed? We do not support ACLs yet and anyway this is NFSv3 case, I believe we should not have any dependency on ACL support for this usecase.
In POSIX systems, only root can change ownership of files (and owner of a file may change the group owner of the file to one of that user's groups). Of course in Linux a non-root user MIGHT be given a CAP to allow it to change ownership, but NFS is not really set up to deal with CAPs. Only with NFSv4 ACLs or RichACLs are non-root users allowed to change ownership of files. Frank
participants (5)
-
Daniel Gryniewicz -
Deepthi Shivaramu -
des＠vmware.com
-
Frank Filz -
Sriram Patil