[Nfs-ganesha-devel] Announce Push of V2.7-dev.14

[Frank Filz]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.Branch next

 

Tag:V2.7-dev.14

 

Release Highlights

 

* Shared code for gtests

 

* Several new gtests including the first batch of NFS v4 layer tests

 

* MDCACHE - Close an unexport race and Fix some subcalls

 

* FSAL_VFS: fix deadlock in vfs_read2

 

* Avoid ABBA kind deadlock while IP release in grace period

 

Signed-off-by: Frank S. Filz 

 

Contents:

 

e34c16d Frank S. Filz V2.7-dev.14

d75c7a0 grajoria gtest/test_handle_to_key_latency: handle_to_key latency
microbenchmark

4865874 Girjesh Rajoria gtest/test_lock_op2_latency: lock_op2 latency
microbenchmark

6fdccc1 Sachin Punadikar Avoid ABBA kind deadlock while IP release in grace
period

7bc99d7 Fatih Acar FSAL_VFS: fix deadlock in vfs_read2

03e4aa1 Supriti Singh Man page: Add a new line to make it readable

7bd8708 Daniel Gryniewicz MDCACHE - Fix some subcalls

d287a4e Daniel Gryniewicz MDCACHE - Close an unexport race

cc12f36 Frank S. Filz gtest: nfs4_op_putfh

2e9c202 Frank S. Filz gtest: nfs4_op_lookup

27176b3 Frank S. Filz gtest: Add GaeshaNFS4BaseTest to collect common NFS v4
code

589bc08 Frank S. Filz gtest: Add GaeshaFSALBaseTest to collect common FSAL
code

3170725 Frank S. Filz NFSv4: Pull op_ctx->ctx_export cleanup out of
compound_data_free

2b65741 Frank S. Filz Update .gitignore to ignore some generated files

84b48f0 Frank S. Filz Make nfs_file_handle.h compile under C++

55d41cf Daniel Gryniewicz Add library for gtest microbenchmarks

--
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

Re: [Nfs-ganesha-devel] ACE permission check

[Frank Filz]

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

Re: [Nfs-ganesha-devel] ACE permission check

[J. Bruce Fields]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.
On Fri, May 25, 2018 at 08:10:07PM +0530, Sagar M D wrote:
>  Hi,
> 
> 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.

What's the ACL on the child?  The rule from Windows at least is that
you only need DELETE or DELETE_CHILD, not both.

> 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.

knfsd implements everything in terms of posix ACLs which never consider
DELETE_CHILD part of write permissions, and never allow DELETE.

--b.

--
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

Re: [Nfs-ganesha-devel] ACE permission check

[Daniel Gryniewicz]

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?


Daniel

On 05/25/2018 07:36 AM, Sagar M D wrote:

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.



Hi,

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

[Nfs-ganesha-devel] ACE permission check

[Sagar M D]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org. Hi,

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

[Nfs-ganesha-devel] ACE permission check

[Sagar M D]

This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.Hi,

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