One thing, I suggest you subscribe to the nfs-ganesha-devel mailing list. I have made it so your responses should go through without being a member, but you risk missing a response if someone doesn't reply-all (or worse, we risk missing a response that is just sent to you).
> -----Original Message----- > From: Satya Prakash GS [mailto:g.satyaprak...@gmail.com] > Sent: Tuesday, February 14, 2017 2:07 PM > To: nfs-ganesha-devel@lists.sourceforge.net > Subject: Re: [Nfs-ganesha-devel] reg. FSAL_ACE_PERM_WRITE_DATA check > in fsal_check_setattr_perms > > >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. > > Can Ganesha avoid doing this check and call test_access always with the > constructed access_mask. I see nothing should be broken because of this. This wouldn't actually help since the call to test_access just winds up in fsal_test_access which isn't going to know about your special super user. All Ganesha is doing here is not making a test_access call that turns into an fsal_test_access call that would always fail the permission check - or actually, I think it might always pass the permission check for files that don't have an NFS v4 ACL... We would have to change the test_access API to add permissions to check for in mode tests that are outside the mode permission checking... The alternative as a general mechanism is to increase the number of calls to the underlying filesystem Ganesha makes which is likely to have a negative impact on other FSAL's performance. > >> 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. > > This could mean interpreting an existing acl and building a new acl if an acl > exists on that file. Does your FSAL/filesystem support NFS v4 ACLs? That would add complexity, however, if you have additional super users that aren't represented in the ACL, that may cause additional issues anywhere Ganesha has special rules for the super user. Frank --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ 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
