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
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
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
participants (3)
-
Frank Filz -
Madhu P Punjabi -
Malahal Naineni