9:46 a.m.
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
9:55 a.m.
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(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
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
7:56 a.m.
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
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(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
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
2099
days inactive
2235
days old
4 comments
3 participants
participants (3)
-
Frank Filz -
Madhu P Punjabi -
Malahal Naineni