The create calls and unlink all rely on the underlying filesystem to do
permission checks. This is because there is no way for Ganesha to atomically
check permissions in a directory and do an operation that adds or removes a
directory entry.
Also, some FSAL_VFS operations set the thread credentials so that quota
accounting and enforcement works properly.
So is_superuser can’t override the underlying filesystem’s notion of who is a
superuser, it can only provide a mechanism for Ganesha to determine if a
particular user is a superuser so that it can do the permission checks it does
correctly.
Frank
From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Tuesday, April 10, 2018 8:13 AM
To: nfs-ganesha-devel@lists.sourceforge.net
Subject: [Nfs-ganesha-devel] is_superuser fsal export API
Hi,
This is in reference to the discussion we had on the concall.
We were experimenting with the is_superuser API call to allow a user other than
the root to act as super user. This API call is not used by any of the FSALs
currently. When using FSAL VFS, we found out that this mechanism works well in
case of setattr (chown, chgrp, etc). But, all the create calls fail with
permission denied. This is happening because in function vfs_open2, we set the
uid/gid to the creds in op_ctx before calling openat. This brings in the linux
access check into picture and if the superuser is not owner of the parent
directory, this call fails with EACCESS.
Is this expected?
Thanks,
Sriram
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
