In some environmentalists, a root may not be able to open a file but the file owner can open. That is why owner and root are tried. 

On Tue, 7 May 2019 at 10:25 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:

Oops, Daniel pointed out that if the open with creds fails, GPFS retries as root…

 

Back to the drawing board, we need more information about what is actually occurring.

 

Frank

 

From: Frank Filz [mailto:ffilzlnx@mindspring.com]
Sent: Tuesday, May 7, 2019 9:46 AM
To: devel@lists.nfs-ganesha.org; 'Madhu P Punjabi' <madhu.punjabi@in.ibm.com>; 'Malahal Naineni' <malahal@gmail.com>
Subject: [NFS-Ganesha-Devel] GPFS LogCrit on lock_op2

 

On the call, I mentioned I would look at bypassing permission check for the file owner for the open_func call in fsal_find_fd with open_for_locks.

 

It turns out there is a difference between FSAL_GPFS and FSAL_VFS

 

FSAL_VFS makes the ultimate call to open_by_handle as root, and therefor even a non-owner of the file will not be an issue in opening the file read/write.

 

GPFS calls GPFSFSAL_open which calls fsal_set_credentials so if the permissions do not allow read/write when open_for_locks occurs, then the file will instead be opened in the same mode as the OPEN stateid.

 

I think it would be good to evaluate when GPFSFSAL_open actually needs to be called, and whether open_func should make a more direct call to fsal_internal_handle2fd.

 

Frank