[Nfs-ganesha-devel] Change in ffilz/nfs-ganesha[next]: Use pseudopath instead of fullpath in NFS v4 situations

[GerritHub]

>From Frank Filz :

Frank Filz has uploaded a new change for review. ( 
https://review.gerrithub.io/348516


Change subject: Use pseudopath instead of fullpath in NFS v4 situations
..

Use pseudopath instead of fullpath in NFS v4 situations

Change-Id: Id48f733e0b49ad0f6ab6d7f9193c12799f25c24b
Signed-off-by: Frank S. Filz 
---
M src/Protocols/NFS/nfs4_op_lookup.c
M src/Protocols/NFS/nfs4_op_lookupp.c
M src/Protocols/NFS/nfs4_op_readdir.c
M src/Protocols/NFS/nfs4_op_secinfo.c
M src/SAL/nfs4_state.c
M src/support/exports.c
M src/support/nfs_creds.c
7 files changed, 36 insertions(+), 36 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/16/348516/1
-- 
To view, visit https://review.gerrithub.io/348516
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: Id48f733e0b49ad0f6ab6d7f9193c12799f25c24b
Gerrit-Change-Number: 348516
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 
--
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] Change in ffilz/nfs-ganesha[next]: When logging exports, use the appropriate fullpath or pseudo...

[GerritHub]

>From Frank Filz :

Frank Filz has uploaded a new change for review. ( 
https://review.gerrithub.io/348517


Change subject: When logging exports, use the appropriate fullpath or pseudopath
..

When logging exports, use the appropriate fullpath or pseudopath

If the export is being logged for NFS V4, always use pseudopath,
otherwise, use fullpath unless mount_path_pseudo config option is
true.

Change-Id: I81c20ad09a34d8c63994147f2a5341988ca14d31
Signed-off-by: Frank S. Filz 
---
M src/MainNFSD/nfs_worker_thread.c
M src/SAL/state_lock.c
M src/include/export_mgr.h
M src/support/exports.c
4 files changed, 40 insertions(+), 25 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/17/348517/1
-- 
To view, visit https://review.gerrithub.io/348517
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I81c20ad09a34d8c63994147f2a5341988ca14d31
Gerrit-Change-Number: 348517
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Frank Filz 
--
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] how does ganesha limit number of FDs

[Frank Filz]

Open fd tracking is an area Ganesha actually needs some additional work, 
however, the tracking in the non-support_ex methods did not limit the number of 
NFS v4 opens in any way, it just was used to manage how many fds Ganesha kept 
open for I/O access to files.



With support_ex, an fd is associated with each file clients have open (NFS v4), 
and additional fds are (may) be used per file/lock owner pair.



Ultimately we do need to have a limit on how much state (NFS v4 open, 
NLM_SHARE, locks, delegations, layouts) is active.



Frank



From: Naresh Babu [mailto:snareshb...@gmail.com]
Sent: Saturday, February 11, 2017 4:21 PM
To: nfs-ganesha-devel@lists.sourceforge.net
Subject: [Nfs-ganesha-devel] how does ganesha limit number of FDs



If a particular FSAL implements extended ops like open2/write2/read2/commit2, 
open_fd_count doesn't get tracked. Then, how does ganesha limit the number of 
open FDs? In general, what is the rationale behind not tracking open fd count?



Thanks,

Naresh



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
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] reg. FSAL_ACE_PERM_WRITE_DATA check in fsal_check_setattr_perms

[Frank Filz]

> Looking at the code, we don't check WRITE_DATA for owner checks, only for
> size or time changes.  For owner/group changes, we check
> FSAL_ACE_PERM_WRITE_OWNER, which is the correct ACL to check.
> 
> Presumably, you could just add an ACL to all files allowing all access to
your
> "root" user.  This should allow access, correct?

This would be a solution.

> On 02/13/2017 09:31 AM, Satya Prakash GS wrote:
> > Hi,
> >
> > Ganesha seems to be checking for FSAL_ACE_PERM_WRITE_DATA
> permission
> > to change owner/group perms (in the function
> > fsal_check_setattr_perms). In our filesystem, there is another user
> > who is equivalent to the root user. This user should be able to change
> > owner/group of any file like the root user. Can somebody please
> > explain the rationale behind this check and how our requirement of
> > having another super user can be achieved.

If you need a true additional super-user, Ganesha would really need to have
code added to be able to configure such, and work to allow super-user
privileges everywhere appropriate.

What FSAL and what filesystem are you using?

Frank



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


--
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] reg. FSAL_ACE_PERM_WRITE_DATA check in fsal_check_setattr_perms

[Daniel Gryniewicz]

Looking at the code, we don't check WRITE_DATA for owner checks, only 
for size or time changes.  For owner/group changes, we check 
FSAL_ACE_PERM_WRITE_OWNER, which is the correct ACL to check.

Presumably, you could just add an ACL to all files allowing all access 
to your "root" user.  This should allow access, correct?

Daniel

On 02/13/2017 09:31 AM, Satya Prakash GS wrote:
> Hi,
>
> Ganesha seems to be checking for FSAL_ACE_PERM_WRITE_DATA permission
> to change owner/group perms (in the function
> fsal_check_setattr_perms). In our filesystem, there is another user
> who is equivalent to the root user. This user should be able to change
> owner/group of any file like the root user. Can somebody please
> explain the rationale behind this check and how our requirement of
> having another super user can be achieved.
>
> Thanks,
> Satya.
>
> --
> 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] Change in ffilz/nfs-ganesha[next]: FSAL_PROXY (support_ex without state) : pxy_close2

[GerritHub]

>From Patrice LUCAS :

Patrice LUCAS has uploaded a new change for review. ( 
https://review.gerrithub.io/348446


Change subject: FSAL_PROXY (support_ex without state) : pxy_close2
..

FSAL_PROXY (support_ex without state) : pxy_close2

Change-Id: I9b6eef0a1c1f15f2a9471bb14bb75cee93a18673
Signed-off-by: Patrice LUCAS 
---
M src/FSAL/FSAL_PROXY/handle.c
1 file changed, 7 insertions(+), 0 deletions(-)



  git pull ssh://review.gerrithub.io:29419/ffilz/nfs-ganesha 
refs/changes/46/348446/1
-- 
To view, visit https://review.gerrithub.io/348446
To unsubscribe, visit https://review.gerrithub.io/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: I9b6eef0a1c1f15f2a9471bb14bb75cee93a18673
Gerrit-Change-Number: 348446
Gerrit-PatchSet: 1
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-Owner: Patrice LUCAS 
--
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] reg. FSAL_ACE_PERM_WRITE_DATA check in fsal_check_setattr_perms

[Satya Prakash GS]

Hi,

Ganesha seems to be checking for FSAL_ACE_PERM_WRITE_DATA permission
to change owner/group perms (in the function
fsal_check_setattr_perms). In our filesystem, there is another user
who is equivalent to the root user. This user should be able to change
owner/group of any file like the root user. Can somebody please
explain the rationale behind this check and how our requirement of
having another super user can be achieved.

Thanks,
Satya.

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