This list has been deprecated. Please subscribe to the new devel list at
lists.nfs-ganesha.org.
Thanks Frank for detailed explanation.
I have the folder permission checked in our FSAL then.
I hope calling fsal_test_access function of ganesha should be fine from our
FSAL.
-Sagar.
On Mon, May 28, 2018 at 12:13 PM, Frank Filz <ffilz...@mindspring.com>
wrote:
> Yes, your FSAL could do the permission checks. It should take measures to
> lock the directory(ies) involved in the operation (rename is nasty). Rename
> is the big nasty because it may hide an unlink. If you have more than one
> NFS server process running (Ganesha or otherwise), you should have some way
> of locking out the other NFS servers for proper protection.
>
>
>
> So the problem with rename is thus:
>
>
>
> Start to process Rename d1/f1 to d2/f2 where y exists
>
> Do permission check
>
> User has permission to create file in d2 and has permission to delete f2
>
> Something races, and replaces f2 with a new file which user DOES NOT have
> permission to unlink
>
> Process rename which unlinks the new f2
>
>
>
> If you can lock the directories, you can prevent the race.
>
>
>
> Note that in general I’m not worried about racing with a permission change
> since if the user at one time had permission to do something, the fact that
> we technically allow the user permission to do that after the permission
> was revoked is not terrible. The user could have won the race and got to do
> the thing before he lost permission.
>
>
>
> The problem with rename is the race places a different file in the cross
> hairs AFTER we have done the permission check, a file the user NEVER had
> permission to unlink.
>
>
>
> You may decide this scenario is unlikely and not worry, but it’s the
> ultimate reason we deferred to the filesystem for permission checks of
> directory operations.
>
>
>
> Also, the locking of multiple objects is hard to do correctly to avoid
> deadlock…
>
>
>
> Frank
>
>
>
> *From:* Sagar M D [mailto:sagar...@gmail.com]
> *Sent:* Sunday, May 27, 2018 4:41 AM
> *To:* Frank Filz <ffilz...@mindspring.com>
> *Cc:* d...@redhat.com; nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] ACE permission check
>
>
>
> 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>
> wrote:
>
> This list has been deprecated. Please subscribe to the new devel list at
> lists.nfs-ganesha.org.
> > This list has been deprecated. Please subscribe to the new devel list at
> lists.nfs-
> > 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
> > > 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
>
>
> ------------------------------------------------------------
> ------------------
> 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
