from:"Sagar M D"

[Nfs-ganesha-devel] 2.5 Ganesha with extended API crash

2018-08-20 Thread Sagar M D

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

We seen one crash with below stack trace. And core dump was not not enabled
so i couldn't pin point the issue. But crash may be because of below reason
and it is my hunch. Is this seen before in any  fsal (Ganesha version is
2.5) ?

 
fsal_status_t

create_handle 
(*struct*
fsal_export 

*export_pub 
,
*struct* gsh_buffdesc

**fh_desc *,
*struct* fsal_obj_handle

**pub_handle 
,
*struct* attrlist

*attrs_out 
)

*looks like fh->desc->addr is NULL here,* while copying fsal file handle it
crashed.

16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (1)
/lib64/libc.so.6(+0x35250) [0x7f8a35890250]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (2)
/usr/lib64/ganesha/libfsaltdfs.so(copy_ganesha_fh+0) [0x7f8a32d432e4]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (3)
/usr/lib64/ganesha/libfsaltdfs.so(+0x97f9)
[0x7f8a32d437f9]   --> create_handle frame.
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (4)
/usr/bin/ganesha.nfsd(mdcache_locate_host+0x233) [0x543fab]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (5)
/usr/bin/ganesha.nfsd(mdc_lookup+0x206) [0x54483e]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (6)
/usr/bin/ganesha.nfsd() [0x53770d]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (7)
/usr/bin/ganesha.nfsd(fsal_lookupp+0xed) [0x4319bd]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (8)
/usr/bin/ganesha.nfsd(nfs3_readdirplus+0x5ec) [0x494650]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (9)
/usr/bin/ganesha.nfsd(nfs_rpc_execute+0x1d53) [0x44c20d]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (10)
/usr/bin/ganesha.nfsd() [0x44ca17]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (11)
/usr/bin/ganesha.nfsd() [0x508a7a]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (12)
/lib64/libpthread.so.0(+0x7dc5) [0x7f8a36290dc5]
16609 4217 08/19 11:34:15 2497585   CvBacktracer() - [bt]: (13)
/lib64/libc.so.6(clone+0x6d) [0x7f8a3595273d]

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

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

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

[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

Re: [Nfs-ganesha-devel] ACL support

2018-02-21 Thread Sagar M D

Hi,

Kernel nfs reorders the ACE in ACL and i think it puts more restrictive
ACEs first in the list. But i see NFS Ganesha is not doing it,is reordering
the responsibility of  FSAL ?
Is there any plans to support reordering ?

Thanks,
Sagar.

On Mon, Feb 19, 2018 at 11:43 AM, Sagar M D  wrote:

> Sriram,
>
> Setting ATTR_ACL in supported_attrs helped. Now I could able to get the V4
> ACLs. Thanks!.
>
> Frank,
> Currently we are doing what you are suggesting i.e we are persistently
> saving the in-memory representation of ganesha NFSV4 ACL on disk.
> And I'm not sure whether we are ready to check in our fsal into ganesha
> yet. We will discuss this internally.
>
> Thanks!
>
> On Fri, Feb 16, 2018 at 9:21 PM, Sriram Patil  wrote:
>
>> Thank you for the correction, Frank.
>>
>>
>>
>> Sagar, there are a couple of more things that you have not mentioned yet,
>>
>>
>>
>>1. Have you set ATTR_ACL in supported_attrs field of your FSALs
>>static fsinfo? (check usage of function nfs4_Fattr_Supported to know why
>>this is required)
>>2. You may also want to take a look at ENABLE_RFC_ACL flag. This is
>>not for enabling ACLs but it is used for access checks in
>>fsal_check_access_acl.
>>
>>
>>
>> - Sriram
>>
>>
>>
>> *From: *Frank Filz 
>> *Date: *Friday, February 16, 2018 at 8:19 PM
>> *To: *Sriram Patil , 'Sagar M D' ,
>> 'Supriti Singh' 
>> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net" <
>> nfs-ganesha-devel@lists.sourceforge.net>
>> *Subject: *RE: [Nfs-ganesha-devel] ACL support
>>
>>
>>
>> It isn’t quite true that NFS v4 ACLs are a superset of POSIX ACLs, but
>> that’s another detail.
>>
>>
>>
>> Sriram is right, Ganesha doesn’t support the NFS v3 sideband protocol for
>> POSIX ACLs. At this point Ganesha has the following support for ACLs:
>>
>>
>>
>> FSAL_GLUSTER has a translation from client side NFS v4 ACLs to server
>> side POSIX ACLs. In V2.7 we plan to move this support to the FSAL common
>> code so it is available to more FSALs (and we will hook it up for FSAL_VFS
>> at that point). Note that the conversion is not perfect due to NFS v4 ACLs
>> not actually being a superset of POSIX ACLs.
>>
>>
>>
>> FSAL_GPFS has native support for NFS v4 ACLs.
>>
>>
>>
>> At this time Ganesha is only set up to handle NFS v4 ACLs via the FSAL
>> API. If your file system can support NFS v4 ACLs natively, then all you
>> need to do is provide a mechanism to transfer between Ganesha’s in memory
>> representation of an NFS v4 ACL and your on-disk representation. If your
>> file system can only support POSIX ACLs, then you will need the translation
>> code from FSAL_GLUSTER (or write your own).
>>
>>
>>
>> I’d also like to add my usual plug, if you have an out of tree FSAL, we
>> encourage you to submit your FSAL into the tree. That allows us a better
>> understanding of how Ganesha is being used, and we are less likely to
>> change APIs in a way that breaks your FSAL (or we will change your FSAL
>> with the API change).
>>
>>
>>
>> Frank
>>
>>
>>
>> *From:* Sriram Patil [mailto:srir...@vmware.com]
>> *Sent:* Friday, February 16, 2018 2:51 AM
>> *To:* Sagar M D ; Supriti Singh <
>> supriti.si...@suse.com>
>> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
>> *Subject:* Re: [Nfs-ganesha-devel] ACL support
>>
>>
>>
>> Hi Sagar,
>>
>>
>>
>> I see in your conf file that you are using NFSv4. POSIX acls do not work
>> on NFSv4. NFSv4 acls are a superset of POSIX acls. For using NFSv4 acls you
>> need to use nfs4_getfacl and nfs4_setfacl commands from the client. You can
>> find these commands in nfs4-acl-tools package.
>>
>>
>>
>> - Sriram
>>
>>
>>
>> *From: *Sagar M D 
>> *Date: *Friday, February 16, 2018 at 3:20 PM
>> *To: *Supriti Singh 
>> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net" <
>> nfs-ganesha-devel@lists.sourceforge.net>
>> *Subject: *Re: [Nfs-ganesha-devel] ACL support
>>
>>
>>
>> I quickly checked on VFS FSAL using below EXPORT block. I see same issue
>> on vfs fsal also. Any suggestion here please ?
>>
>>
>>
>> *Operation to request attribute not supported. Failed to instantiate ACL.
>> *
>>
>> EXPORT
>> {
>> Export_Id = 77;
>>
>> # Exported path (mandatory)
>>

Re: [Nfs-ganesha-devel] ACL support

2018-02-19 Thread Sagar M D

Sriram,

I was using nfsv4 acl commands only.

[root@BDC sagar]# nfs4_getfacl 1.txt
Operation to request attribute not supported.

[root@BDC sagar]# nfs4_setfacl  -a A::10:rxtncy 1.txt
Operation to request attribute not supported.
Failed to instantiate ACL.

Thanks,
Sagar.


On Fri, Feb 16, 2018 at 4:20 PM, Sriram Patil  wrote:

> Hi Sagar,
>
>
>
> I see in your conf file that you are using NFSv4. POSIX acls do not work
> on NFSv4. NFSv4 acls are a superset of POSIX acls. For using NFSv4 acls you
> need to use nfs4_getfacl and nfs4_setfacl commands from the client. You can
> find these commands in nfs4-acl-tools package.
>
>
>
> - Sriram
>
>
>
> *From: *Sagar M D 
> *Date: *Friday, February 16, 2018 at 3:20 PM
> *To: *Supriti Singh 
> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net"  sourceforge.net>
> *Subject: *Re: [Nfs-ganesha-devel] ACL support
>
>
>
> I quickly checked on VFS FSAL using below EXPORT block. I see same issue
> on vfs fsal also. Any suggestion here please ?
>
>
>
> *Operation to request attribute not supported. Failed to instantiate ACL. *
>
> EXPORT
> {
> Export_Id = 77;
>
> # Exported path (mandatory)
> Path = /home;
>
> # Pseudo Path (required for NFS v4)
> Pseudo = /home;
>
> # Required for access (default is None)
> # Could use CLIENT blocks instead
> Access_Type = RW;
> Disable_ACL = FALSE;
> NFS_Protocols = 4;
> Squash = no_root_squash;
>
> # Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
> Thanks,
>
> Sagar.
>
>
>
>
>
> On Fri, Feb 16, 2018 at 2:25 PM, Sagar M D  wrote:
>
> Supriti,
>
>
>
> We are testing our own FSAL.
>
> Thanks,
>
> Sagar.
>
>
>
>
>
> On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh 
> wrote:
>
> Hi Sagar,
>
> Which FSAL are you using?
>
>
>
>
>
> --
>
> Supriti Singh
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>
> HRB 21284 (AG Nürnberg)
>
>
> >>> Sagar M D  02/16/18 9:15 AM >>>
>
> Hi,
>
> We are setting below value in our EXPORT block to enable ACL.
> *Disable_ACL = FALSE;*
>
> However when try to do any ACL operation it throws get below error:-
>
> *Operation to request attribute not supported. Failed to instantiate ACL.*
>
> On further analysis, i found that getattr call on our fsal  export's root
> folder is returning 3 (ALLOW | DENY) in aclsupport field. But getattr call
> on pseudo export is returning "0" in aclsupport field.
>
>
>
>
>
> Is there anything else in fsal to be taken care to enable acls ?
>
>
>
> 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

Re: [Nfs-ganesha-devel] ACL support

2018-02-19 Thread Sagar M D

Sriram,

Setting ATTR_ACL in supported_attrs helped. Now I could able to get the V4
ACLs. Thanks!.

Frank,
Currently we are doing what you are suggesting i.e we are persistently
saving the in-memory representation of ganesha NFSV4 ACL on disk.
And I'm not sure whether we are ready to check in our fsal into ganesha
yet. We will discuss this internally.

Thanks!

On Fri, Feb 16, 2018 at 9:21 PM, Sriram Patil  wrote:

> Thank you for the correction, Frank.
>
>
>
> Sagar, there are a couple of more things that you have not mentioned yet,
>
>
>
>1. Have you set ATTR_ACL in supported_attrs field of your FSALs static
>fsinfo? (check usage of function nfs4_Fattr_Supported to know why this is
>required)
>2. You may also want to take a look at ENABLE_RFC_ACL flag. This is
>not for enabling ACLs but it is used for access checks in
>fsal_check_access_acl.
>
>
>
> - Sriram
>
>
>
> *From: *Frank Filz 
> *Date: *Friday, February 16, 2018 at 8:19 PM
> *To: *Sriram Patil , 'Sagar M D' ,
> 'Supriti Singh' 
> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net"  sourceforge.net>
> *Subject: *RE: [Nfs-ganesha-devel] ACL support
>
>
>
> It isn’t quite true that NFS v4 ACLs are a superset of POSIX ACLs, but
> that’s another detail.
>
>
>
> Sriram is right, Ganesha doesn’t support the NFS v3 sideband protocol for
> POSIX ACLs. At this point Ganesha has the following support for ACLs:
>
>
>
> FSAL_GLUSTER has a translation from client side NFS v4 ACLs to server side
> POSIX ACLs. In V2.7 we plan to move this support to the FSAL common code so
> it is available to more FSALs (and we will hook it up for FSAL_VFS at that
> point). Note that the conversion is not perfect due to NFS v4 ACLs not
> actually being a superset of POSIX ACLs.
>
>
>
> FSAL_GPFS has native support for NFS v4 ACLs.
>
>
>
> At this time Ganesha is only set up to handle NFS v4 ACLs via the FSAL
> API. If your file system can support NFS v4 ACLs natively, then all you
> need to do is provide a mechanism to transfer between Ganesha’s in memory
> representation of an NFS v4 ACL and your on-disk representation. If your
> file system can only support POSIX ACLs, then you will need the translation
> code from FSAL_GLUSTER (or write your own).
>
>
>
> I’d also like to add my usual plug, if you have an out of tree FSAL, we
> encourage you to submit your FSAL into the tree. That allows us a better
> understanding of how Ganesha is being used, and we are less likely to
> change APIs in a way that breaks your FSAL (or we will change your FSAL
> with the API change).
>
>
>
> Frank
>
>
>
> *From:* Sriram Patil [mailto:srir...@vmware.com]
> *Sent:* Friday, February 16, 2018 2:51 AM
> *To:* Sagar M D ; Supriti Singh <
> supriti.si...@suse.com>
> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] ACL support
>
>
>
> Hi Sagar,
>
>
>
> I see in your conf file that you are using NFSv4. POSIX acls do not work
> on NFSv4. NFSv4 acls are a superset of POSIX acls. For using NFSv4 acls you
> need to use nfs4_getfacl and nfs4_setfacl commands from the client. You can
> find these commands in nfs4-acl-tools package.
>
>
>
> - Sriram
>
>
>
> *From: *Sagar M D 
> *Date: *Friday, February 16, 2018 at 3:20 PM
> *To: *Supriti Singh 
> *Cc: *"nfs-ganesha-devel@lists.sourceforge.net"  sourceforge.net>
> *Subject: *Re: [Nfs-ganesha-devel] ACL support
>
>
>
> I quickly checked on VFS FSAL using below EXPORT block. I see same issue
> on vfs fsal also. Any suggestion here please ?
>
>
>
> *Operation to request attribute not supported. Failed to instantiate ACL. *
>
> EXPORT
> {
> Export_Id = 77;
>
> # Exported path (mandatory)
> Path = /home;
>
> # Pseudo Path (required for NFS v4)
> Pseudo = /home;
>
> # Required for access (default is None)
> # Could use CLIENT blocks instead
> Access_Type = RW;
> Disable_ACL = FALSE;
> NFS_Protocols = 4;
> Squash = no_root_squash;
>
> # Exporting FSAL
> FSAL {
> Name = VFS;
> }
> }
>
> Thanks,
>
> Sagar.
>
>
>
>
>
> On Fri, Feb 16, 2018 at 2:25 PM, Sagar M D  wrote:
>
> Supriti,
>
>
>
> We are testing our own FSAL.
>
> Thanks,
>
> Sagar.
>
>
>
>
>
> On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh 
> wrote:
>
> Hi Sagar,
>
> Which FSAL are you using?
>
>
>
>
>
> --
>
> Supriti Singh
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Nort

Re: [Nfs-ganesha-devel] ACL support

2018-02-16 Thread Sagar M D

I quickly checked on VFS FSAL using below EXPORT block. I see same issue on
vfs fsal also. Any suggestion here please ?



*Operation to request attribute not supported.Failed to instantiate ACL.*

EXPORT
{
Export_Id = 77;

# Exported path (mandatory)
Path = /home;

# Pseudo Path (required for NFS v4)
Pseudo = /home;

# Required for access (default is None)
# Could use CLIENT blocks instead
Access_Type = RW;
Disable_ACL = FALSE;
NFS_Protocols = 4;
Squash = no_root_squash;

# Exporting FSAL
FSAL {
Name = VFS;
}
}

Thanks,
Sagar.




On Fri, Feb 16, 2018 at 2:25 PM, Sagar M D  wrote:

> Supriti,
>
> We are testing our own FSAL.
>
> Thanks,
> Sagar.
>
>
> On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh 
> wrote:
>
>> Hi Sagar,
>>
>> Which FSAL are you using?
>>
>>
>>
>>
>> --
>> Supriti Singh
>> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>> HRB 21284 (AG Nürnberg)
>>
>> >>> Sagar M D  02/16/18 9:15 AM >>>
>> Hi,
>>
>> We are setting below value in our EXPORT block to enable ACL.
>> *Disable_ACL = FALSE;*
>>
>> However when try to do any ACL operation it throws get below error:-
>>
>> *Operation to request attribute not supported.Failed to instantiate ACL.*
>>
>> On further analysis, i found that getattr call on our fsal  export's root
>> folder is returning 3 (ALLOW | DENY) in aclsupport field. But getattr call
>> on pseudo export is returning "0" in aclsupport field.
>>
>>
>> Is there anything else in fsal to be taken care to enable acls ?
>>
>> 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

Re: [Nfs-ganesha-devel] ACL support

2018-02-16 Thread Sagar M D

Supriti,

We are testing our own FSAL.

Thanks,
Sagar.


On Fri, Feb 16, 2018 at 2:15 PM, Supriti Singh 
wrote:

> Hi Sagar,
>
> Which FSAL are you using?
>
>
>
>
> --
> Supriti Singh
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
>
> >>> Sagar M D  02/16/18 9:15 AM >>>
> Hi,
>
> We are setting below value in our EXPORT block to enable ACL.
> *Disable_ACL = FALSE;*
>
> However when try to do any ACL operation it throws get below error:-
>
> *Operation to request attribute not supported.Failed to instantiate ACL.*
>
> On further analysis, i found that getattr call on our fsal  export's root
> folder is returning 3 (ALLOW | DENY) in aclsupport field. But getattr call
> on pseudo export is returning "0" in aclsupport field.
>
>
> Is there anything else in fsal to be taken care to enable acls ?
>
> 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] ACL support

2018-02-16 Thread Sagar M D

Hi,

We are setting below value in our EXPORT block to enable ACL.
*Disable_ACL = FALSE;*

However when try to do any ACL operation it throws get below error:-

*Operation to request attribute not supported.Failed to instantiate ACL.*

On further analysis, i found that getattr call on our fsal  export's root
folder is returning 3 (ALLOW | DENY) in aclsupport field. But getattr call
on pseudo export is returning "0" in aclsupport field.


Is there anything else in fsal to be taken care to enable acls ?

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

Re: [Nfs-ganesha-devel] owner and group issue.

2018-02-15 Thread Sagar M D

Thanks! we will add support_ex functionality in our fsal as part of that
will see if the issue in question goes away.

On Mon, Feb 12, 2018 at 12:02 PM, Frank Filz 
wrote:

> If you are not using open2, then file creation could easily be wonky. Also
> note that the non-support_ex functionality is being deprecated so your FSAL
> would need to be converted to support_ex if you wish to migrate to newer
> Ganesha (and there will be lots of reasons to migrate to V2.6 and later as
> we move forward).
>
>
>
> Frank
>
>
>
> *From:* Sagar M D [mailto:sagar...@gmail.com]
> *Sent:* Sunday, February 11, 2018 6:27 AM
> *To:* d...@redhat.com
> *Cc:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* Re: [Nfs-ganesha-devel] owner and group issue.
>
>
>
> Daniel,
>
>
>
> We are using open call not open2 call. But i verified our FSAL is
> returning correct owner and group id for getattr call right after file gets
> created.
>
> And it is intermittent issue and can be reproduced easily.  This is
> happening basically during process starts.
>
>
>
> Thanks,
>
> Sagar.
>
>
>
>
>
> On Thu, Feb 8, 2018 at 10:30 PM, Daniel Gryniewicz 
> wrote:
>
> This is not a known issue, as far as I'm aware.
>
> I'm assuming you never changed 4.txt at all, it just fixed itself on it's
> own?  This means, to me, that the correct value is being set on the file,
> but an incorrect one is returned to the user.  That's a getattr() issue,
> and it resolves itself because after 60 seconds, the attribute cache
> expires, and so the next getattr refreshes the cache, fixing the issue.
>
> Is your FSAL correctly returning the attributes in attrs_out in it's
> open2() call?
>
> Daniel
>
>
>
> On 02/08/2018 05:15 AM, Sagar M D wrote:
>
> Hi,
>
> We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file
> have -2 has owner and group even though root is created the file and
> no_root_squash is enabled.
>
> I see this behavior for only for short duration that to right after
> ganesha restarts.
>
> During file creation, our fsal gets correct owner and group. But ls -ltr
> is showing -2. If i try after few mins all works fine.
>
> [root@BDC testPerm]# touch 4.txt
> [root@BDC testPerm]# ls -ltr
> total 0
> -rw-r--r--. 1 root   root   0 Feb  7 20:10 1.txt
> -rw-r--r--. 1 root   root   0 Feb  7 20:17 2.txt
> -rw-r--r--. 1 root   root   0 Feb  7 20:17 3.txt
> -rw-r--r--. 1 4294967294 4294967294 0 Feb  7 20:21 4.txt
>
>
> ls tried after some time:-
> [root@BDC testPerm]# touch 5.txt
> [root@BDC testPerm]# ls -ltr
> total 0
> -rw-r--r--. 1 root root 0 Feb  7 20:10 1.txt
> -rw-r--r--. 1 root root 0 Feb  7 20:17 2.txt
> -rw-r--r--. 1 root root 0 Feb  7 20:17 3.txt
> -rw-r--r--. 1 root root 0 Feb  7 20:21 4.txt
> -rw-r--r--. 1 root root 0 Feb  7 20:33 5.txt
>
> is there any known issues ? Are we missing anything from our side?
>
> 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
>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
> <#m_5155678442422528623_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
--
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] owner and group issue.

2018-02-11 Thread Sagar M D

Daniel,

We are using open call not open2 call. But i verified our FSAL is returning
correct owner and group id for getattr call right after file gets created.
And it is intermittent issue and can be reproduced easily.  This is
happening basically during process starts.

Thanks,
Sagar.


On Thu, Feb 8, 2018 at 10:30 PM, Daniel Gryniewicz  wrote:

> This is not a known issue, as far as I'm aware.
>
> I'm assuming you never changed 4.txt at all, it just fixed itself on it's
> own?  This means, to me, that the correct value is being set on the file,
> but an incorrect one is returned to the user.  That's a getattr() issue,
> and it resolves itself because after 60 seconds, the attribute cache
> expires, and so the next getattr refreshes the cache, fixing the issue.
>
> Is your FSAL correctly returning the attributes in attrs_out in it's
> open2() call?
>
> Daniel
>
>
> On 02/08/2018 05:15 AM, Sagar M D wrote:
>
>> Hi,
>>
>> We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file
>> have -2 has owner and group even though root is created the file and
>> no_root_squash is enabled.
>>
>> I see this behavior for only for short duration that to right after
>> ganesha restarts.
>>
>> During file creation, our fsal gets correct owner and group. But ls -ltr
>> is showing -2. If i try after few mins all works fine.
>>
>> [root@BDC testPerm]# touch 4.txt
>> [root@BDC testPerm]# ls -ltr
>> total 0
>> -rw-r--r--. 1 root   root   0 Feb  7 20:10 1.txt
>> -rw-r--r--. 1 root   root   0 Feb  7 20:17 2.txt
>> -rw-r--r--. 1 root   root   0 Feb  7 20:17 3.txt
>> -rw-r--r--. 1 4294967294 4294967294 0 Feb  7 20:21 4.txt
>>
>>
>> ls tried after some time:-
>> [root@BDC testPerm]# touch 5.txt
>> [root@BDC testPerm]# ls -ltr
>> total 0
>> -rw-r--r--. 1 root root 0 Feb  7 20:10 1.txt
>> -rw-r--r--. 1 root root 0 Feb  7 20:17 2.txt
>> -rw-r--r--. 1 root root 0 Feb  7 20:17 3.txt
>> -rw-r--r--. 1 root root 0 Feb  7 20:21 4.txt
>> -rw-r--r--. 1 root root 0 Feb  7 20:33 5.txt
>>
>> is there any known issues ? Are we missing anything from our side?
>>
>> 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

[Nfs-ganesha-devel] owner and group issue.

2018-02-08 Thread Sagar M D

Hi,

We are using nfs-ganesha 2.5 for our fsal, I see sometimes created file
have -2 has owner and group even though root is created the file and
no_root_squash is enabled.

I see this behavior for only for short duration that to right after ganesha
restarts.

During file creation, our fsal gets correct owner and group. But ls -ltr is
showing -2. If i try after few mins all works fine.

[root@BDC testPerm]# touch 4.txt
[root@BDC testPerm]# ls -ltr
total 0
-rw-r--r--. 1 root   root   0 Feb  7 20:10 1.txt
-rw-r--r--. 1 root   root   0 Feb  7 20:17 2.txt
-rw-r--r--. 1 root   root   0 Feb  7 20:17 3.txt
-rw-r--r--. 1 4294967294 4294967294 0 Feb  7 20:21 4.txt


ls tried after some time:-
[root@BDC testPerm]# touch 5.txt
[root@BDC testPerm]# ls -ltr
total 0
-rw-r--r--. 1 root root 0 Feb  7 20:10 1.txt
-rw-r--r--. 1 root root 0 Feb  7 20:17 2.txt
-rw-r--r--. 1 root root 0 Feb  7 20:17 3.txt
-rw-r--r--. 1 root root 0 Feb  7 20:21 4.txt
-rw-r--r--. 1 root root 0 Feb  7 20:33 5.txt

is there any known issues ? Are we missing anything from our side?

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] MNT3ERR_ACCESS vs MNT3ERR_NOTSUPP

2016-09-08 Thread Sagar M D

*Hi All,In *
*mnt_Mnt 
function, I see if the share is exported with only v4 and clients try
to mount using v3 then "access denied by server" error is returned to
client from the server. I feel "*MNT3ERR_NOTSUPP" should be returned
from here. so client can know v3 is not supported on this exported
share.

*if* ((op_ctx 
->export_perms
->options

& EXPORT_OPTION_NFSV3
)
== 0) {
LogInfo 
(COMPONENT_NFSPROTO
,
"MOUNT: Export entry %s does not support NFS v3 for 
client %s",
export 
->fullpath
,
op_ctx 
->client

? op_ctx 
->client
->hostaddr_str

: "unknown client");
res 
->res_mnt3
.fhs_status

= MNT3ERR_ACCES;
*goto* out 
;
}
Please let me know, if returning "MNT3ERR_ACCESS" is fine here ?

Thanks,

Sagar
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Re: [Nfs-ganesha-devel] lock_op

2016-09-08 Thread Sagar M D

That really helped. Much appreciated Frank.

-Sagar

On Wed, Sep 7, 2016 at 7:01 PM, Frank Filz  wrote:

> Owner is an opaque value to the FSAL. It happens to be the pointer to a
> state_lock_owner_t so Ganesha does expect it back on call backs when async
> blocking locks are supported (see other e-mail chain for issues that are
> arising without that support). Ganesha never dereferences the owner value
> from the FSAL however, it just searches its blocked locks list for locks
> with the same owner.
>
>
>
> The FSAL may use it in any way it chooses to differentiate lock owners.
>
>
>
> I should note that all new FSAL development should use the support_ex API,
> where there will be a state_t object for each lock owner/file pair. This
> actually allows the FSAL to define it’s own lock owner in whatever way
> makes sense (but the opaque void * lock owner is also still available).
>
>
>
> I hope that helps,
>
>
>
> Frank
>
>
>
> *From:* Sagar M D [mailto:sagar...@gmail.com]
> *Sent:* Wednesday, September 7, 2016 3:37 PM
> *To:* nfs-ganesha-devel@lists.sourceforge.net
> *Subject:* [Nfs-ganesha-devel] lock_op
>
>
>
> Hi All,
>
>
>
> could someone please shed light on the usage of "owner" in fsal side ? Is
> "owner" implemented as comments says "it is not yet".
>
>
>
> Also "owner" looks  opaque to FSAL. Will NFS-Ganesha expects this back in
> any call ?
>
>
>
>  how fsal should use this "owner" ?
>
>
>
> /**
>
> * @brief Perform a lock operation
>
> *
>
> * This function performs a lock operation (lock, unlock, test) on a
>
> * file.
>
> *
>
> * @param[in] obj_hdl File on which to operate
>
> * @param[in] owner Lock owner (Not yet implemented)
>
> * @param[in] lock_op Operation to perform
>
> * @param[in] request_lock Lock to take/release/test
>
>
>
> * @param[out] conflicting_lock Conflicting lock
>
> *
>
> * @return FSAL status.
>
> */
>
> fsal_status_t (*lock_op)(struct fsal_obj_handle *obj_hdl,
>
> void *owner,
>
> fsal_lock_op_t lock_op,
>
> fsal_lock_param_t *request_lock,
>
> fsal_lock_param_t *conflicting_lock);
>
>
>
> Thanks,
>
> Sagar
>
>
> --
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] lock_op

2016-09-07 Thread Sagar M D

Hi All,


could someone please shed light on the usage of "owner" in fsal side ? Is
"owner" implemented as comments says "it is not yet".


Also "owner" looks  opaque to FSAL. Will NFS-Ganesha expects this back in
any call ?


 how fsal should use this "owner" ?


/**

* @brief Perform a lock operation

*

* This function performs a lock operation (lock, unlock, test) on a

* file.

*

* @param[in] obj_hdl File on which to operate

* @param[in] owner Lock owner (Not yet implemented)

* @param[in] lock_op Operation to perform

* @param[in] request_lock Lock to take/release/test



* @param[out] conflicting_lock Conflicting lock

*

* @return FSAL status.

*/

fsal_status_t (*lock_op)(struct fsal_obj_handle *obj_hdl,

void *owner,

fsal_lock_op_t lock_op,

fsal_lock_param_t *request_lock,

fsal_lock_param_t *conflicting_lock);


Thanks,

Sagar
--
___
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

[Nfs-ganesha-devel] 2.5 Ganesha with extended API crash

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

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

[Nfs-ganesha-devel] ACE permission check

[Nfs-ganesha-devel] ACE permission check

Re: [Nfs-ganesha-devel] ACL support

Re: [Nfs-ganesha-devel] ACL support

Re: [Nfs-ganesha-devel] ACL support

Re: [Nfs-ganesha-devel] ACL support

Re: [Nfs-ganesha-devel] ACL support

[Nfs-ganesha-devel] ACL support

Re: [Nfs-ganesha-devel] owner and group issue.

Re: [Nfs-ganesha-devel] owner and group issue.

[Nfs-ganesha-devel] owner and group issue.

[Nfs-ganesha-devel] MNT3ERR_ACCESS vs MNT3ERR_NOTSUPP

Re: [Nfs-ganesha-devel] lock_op

[Nfs-ganesha-devel] lock_op

17 matches

Site Navigation

Mail list logo

Footer information