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

2018-05-29 Thread Daniel Gryniewicz 

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

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

2018-05-29 Thread Frank Filz 
This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.I can’t think of any reason it would be an issue.

 

Frank

 

From: Sagar M D [mailto:sagar...@gmail.com] 
Sent: Monday, May 28, 2018 5:37 AM
To: Frank Filz 
Cc: d...@redhat.com; nfs-ganesha-devel@lists.sourceforge.net
Subject: Re: [Nfs-ganesha-devel] ACE permission check

 

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 mailto: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 <mailto:sagar...@gmail.com> ] 
Sent: Sunday, May 27, 2018 4:41 AM
To: Frank Filz mailto:ffilz...@mindspring.com> >
Cc: d...@redhat.com <mailto:d...@redhat.com> ; 
nfs-ganesha-devel@lists.sourceforge.net 
<mailto: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 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.
> >

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

2018-05-28 Thread Sagar M D 
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:
> > > Ev

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

2018-05-28 Thread Frank Filz 
This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.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 
<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 comm

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

2018-05-27 Thread Sagar M D 
This list has been deprecated. Please subscribe to the new devel list at 
lists.nfs-ganesha.org.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 
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

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

2018-05-25 Thread 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

2018-05-25 Thread 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

2018-05-25 Thread 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

2018-05-25 Thread 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

2018-05-25 Thread 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