Hi Frank,

Thank you very much for checking about this.

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

We will analyse the call made to GPFSFSAL_open. Thank you for pointing this out.

Thanks,
Madhu Thorat
IBM-India Software Labs, Pune.

----- Original message -----
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: <devel@lists.nfs-ganesha.org>, "'Madhu P Punjabi'" <madhu.punjabi@in.ibm.com>, "'Malahal Naineni'" <malahal@gmail.com>
Cc:
Subject: GPFS LogCrit on lock_op2
Date: Tue, May 7, 2019 10:16 PM

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