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