Frank, I have subscribed to the list. Apologies for any inconvenience caused.
> 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. Our filesystem doesn't support NFSv4 ACLs. Sorry to prolong this further but just to be clear, we have implemented our own test_access call. In our test_access implementation we have a way to figure out if the user is super user or not. Agree that removing the check would result in a lot of fsal_test_access calls. On Wed, Feb 15, 2017 at 3:57 AM, Frank Filz <ffilz...@mindspring.com> wrote: > 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 > Thanks, Satya. ------------------------------------------------------------------------------ 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
