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

[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

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

OWNER was not user) if (FSAL_TEST_MASK(attr->valid_mask, ATTR_OWNER)) { /* non-root is only allowed to "take ownership of file" */

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

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

ACL to check) if (current->acl) { status = obj->obj_ops->test_access(obj, access_check,

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

for this usecase.

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-confi... On 11 Mar 2020 22:14, Frank Filz <ffilzlnx(a)mindspring.com&gt; 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(a)mindspring.com>; devel(a)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(a)mindspring.com&gt; 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(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org

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.