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(a)mindspring.com> wrote:
Oops, Daniel pointed out that if the open with creds fails, GPFS
Back to the drawing board, we need more information about what is actually
*From:* Frank Filz [mailto:email@example.com]
*Sent:* Tuesday, May 7, 2019 9:46 AM
*To:* devel(a)lists.nfs-ganesha.org; 'Madhu P Punjabi' <
madhu.punjabi(a)in.ibm.com>; 'Malahal Naineni' <malahal(a)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
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