On 02/14/2017 06:48 AM, Satya Prakash GS wrote:
> I was referring to this check --->
>
> if (access_check != FSAL_ACE4_MASK_SET(FSAL_ACE_PERM_WRITE_DATA)) {
>   status = CACHE_INODE_FSAL_EPERM;
>   note = "(no ACL to check)";
>   goto out;
> }

Sorry, I assumed an ACL existed on the file.  What this check is saying 
is that, if there's no ACL, the finest granularity check we can do is 
unix permission bits, which is just Read Write Execute (and Write is the 
only relevant one here), so only continue if we're looking for Write access.

> which is done if the user is not owner of the file.
>
> As per the code,  user can do chown if he is owner or if there is an
> acl on the file. Can Ganesha just pass the credentials (uid, gid) on
> to the server for it to decide if chown is allowed on that file by a
> particular user (irrespective of acls set on that file). That way,
> certain users can be treated specially by the server and grant them
> access.
>
>>> Looking at the code, we don't check WRITE_DATA for owner checks, only for
>>> size or time changes.  For owner/group changes, we check
>>> FSAL_ACE_PERM_WRITE_OWNER, which is the correct ACL to check.
>>>
>>> Presumably, you could just add an ACL to all files allowing all access to
> your
>>> "root" user.  This should allow access, correct?
>
>> This would be a solution.
>
> I am trying to see if we can avoid any on-disk changes. Since NFS is
> one of the ways to access filesystem it would be better if we can
> avoid handling it differently.

You don't have to do this in the filesystem; you can have the getattrs() 
in your FSAL just always add an ACL to the beginning that allows all 
access to your superuser.

>
>> On 02/13/2017 09:31 AM, Satya Prakash GS wrote:
>>> Hi,
>>>
>>> Ganesha seems to be checking for FSAL_ACE_PERM_WRITE_DATA
>> permission
>>> to change owner/group perms (in the function
>>> fsal_check_setattr_perms). In our filesystem, there is another user
>>> who is equivalent to the root user. This user should be able to change
>>> owner/group of any file like the root user. Can somebody please
>>> explain the rationale behind this check and how our requirement of
>>> having another super user can be achieved.
>
>> If you need a true additional super-user, Ganesha would really need to have
>> code added to be able to configure such, and work to allow super-user
>> privileges everywhere appropriate.
>
>> What FSAL and what filesystem are you using?
>
> We have our own filesystem and FSAL.

I'm not in favor, at this point, of a configurable for setting the 
superuser ID, unless we can come up with a more common use case.  I'd 
try the ACL hack mentioned above.

Daniel


------------------------------------------------------------------------------
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

Reply via email to