> Certain checks are delegated to the FSALs, for performance reasons. The > access check on unlink is one of these (see fsal_remove()). If you build with > ENABLE_RFC_ACL, it will perform those checks in the common code, but this > will result in more getattrs() calls into the FSAL, which raises latency of ops. > > The reasoning is that the underlying filesystem must make these permission > checks anyway, and these checks can be done inline with the remove on the > cluster, rather then requiring a separate round-trip to the cluster. > > If you need to implement this in Ganesha rather than the underlying > filesystem, you can call fsal_remove_access() to check for unlink permission > from your FSAL. Or, you can compile with ENABLE_RFC_ACL.
Actually, the reason we delegate permission checking for operations that add or remove directory entries is for correctness. Rename especially can result in a client being able to remove a file it should not have due to races. Delegating this permission checking to the underlying filesystem also assures that things like sticky bit directories are also properly handled. It also allows a filesystem that implements NFS v4 ACLs or Rich ACLs to properly handle delete permission on an individual file. Frank > On 05/10/2017 02:45 AM, Naresh Babu wrote: > > Like all other NFS ops, unlink/remove is preceded by an access call. > > nfs3_access on parent directory (under which file is being removed) > > returns a response with res->res_access3.ACCESS3res_u.resok.access set > > to permissions allowed on the parent directory. Since the current user > > doesn't have write permission on parent directory, > > res->res_access3.ACCESS3res_u.resok.access is set to 3. After this > > response, client issues remove call and there are no checks in > > nfs/fsal layers to prevent unlink from happening. Similar behavior can > > be observed with file/directory create. But, file writes are not > > issued by the client when access check response has no write access > > set for the file. I am using v2.4-stable build and implemented only > > NFS v3 ops in custom FSAL. I can add access checks in create/unlink to > > prevent these issues. But, I want to know if there is something wrong in my > understanding. > > > > Thanks, > > Naresh > > > > > > ---------------------------------------------------------------------- > > -------- 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 > > > > > ---------------------------------------------------------------------------- -- > 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 --- 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
