This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.
If you take a look at code protected by ENABLE_VFS_DEBUG_ACL, you can see a test implementation of ACL enforcement I added to VFS a few years ago. It should be as complete as can be done using mode. It may have bit-rotted a bit by now.

Daniel

On 05/27/2018 07:40 AM, Sagar M D wrote:
Frank/Daniel,

Creds are correct,  ACL implementation in our FSAL is new, basic RWX permission is enforced in our FSAL on this path. Currently ACL's are not enforced in our Filesystem. We are relying on ganesha to enforce ACL. can our FSAL make call to /fsal_test_access instead (wherever we need to enforce) ?

/
/P.S:- Our filesystem is accessed either through nfs Ganesha or our own nfs server (anyone will be active at given time).
/
/
Thanks,
/
/Sagar.
/


On Fri, May 25, 2018 at 10:14 PM, Frank Filz <ffilz...@mindspring.com <mailto:ffilz...@mindspring.com>> wrote:

    This list has been deprecated. Please subscribe to the new devel
    list at lists.nfs-ganesha.org <http://lists.nfs-ganesha.org>.
    > This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-
    > ganesha.org <http://ganesha.org>.
    > So, the access check is, of course, advisory to the client.  It doesn't 
have to
    > make one at all, but can just issue the rename, and expect it to succeed 
or fail
    > based on permissions.  I'm not sure why the client does an access and 
then still
    > does a rename, but it ultimately doesn't matter, I think.
> > We don't do an extra access check in the rename path, because it could race
    > with a permissions change anyway.  Instead, we rely on the FSAL's
    > rename() call to properly enforce permissions.  This is the way many 
calls work in
    > the FSAL API, to avoid those races.
> > Does your rename() call not enforce permissions?  Or did it somehow succeed in
    > spite of that?  Were the wrong creds passed in?

    Yea, while Ganesha does some permission checking itself, it MUST
    depend on the FSAL and its underlying filesystem to permission check
    any directory operations. This is due to the issues of making a
    permission check atomic with the operation.

    What kind of ACLs does your FSAL and filesystem implement? Does the
    filesystem have mechanisms to enforce the ACL?

    Do you set/pass the user credentials for the operations? See what
    FSAL_VFS and FSAL_GLUSTER do for examples.

    Frank

    > > By looking at nfs-Ganesha code, permission check (ACL) happens
    > > access_check.c. Our FSAL (not in tree FSAL), storing and serving the
    > > ACLs to Ganesha.
    > >
    > > I see an issue with rename:
    > > Even though i set deny ACE for "delete child" on folder1 for user1.
    > > user1 is able to rename file belongs to user2.
    > >
    > > I see below RPC:-
    > > ACCESS request folder1
    > > ACCESS denied (as expected.) (denied for DELETE_CHILD permission)
    > > Rename request Rename succeed
    > >
    > > I'm not sure why client is sending rename even after receiving  ACCESS
    > > Denied.
    > >
    > > Native nfs denies rename though.
    > >
    > > Any help is appreciated here.
    > >
    > > Thanks,
    > > Sagar.
    > >
    > >
    > >
    > >
    > > ----------------------------------------------------------------------
     > > -------- 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
    <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
     > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
    <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
    <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
     > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
    <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
    <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
    <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

Reply via email to