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.