phdeniel/nfs-ganesha — Issue #24: Lock and IO permissions
Author: jvrao
Created: 2011-11-18 02:10:27+00:00
State: open

I have done some investigation on what level of permission/access checks are done during LOCK and IO requests on NFSv3 and NFSv4. I have compared and contrasted the behavior of kNFS(Kernel NFS) and Ganesha. Here are my observations.

POSIX Behavior:
Access check is done at the time of open().
Since then the IO and Lock operations are only checked against the filehandle, not
with the current credentials of the file.

NFSv3:

kNFS:
- Not much permission checks; No permission checking in NLM code.
- The first lock request need to agree with the opened fd. From then on no checking.
If a file is opened for read:
- A read lock followed by a write lock allowed
- If you attempt a write lock first it will fail.
- IO that is incompatible with the file permissions at that time will fail.

Ganesha:
- Not much permission checks
- File need R+W access to get any lock. One can't get readlock on a read=only file.
- Can do IO that is incompatible with the file permissions at the time of IO

NFSv4
kNFS:
- Lock request compatibility is tested with the file permissions at the time of lock request.
- No dependency of the open stateid.

Ganesha:
- Mostly like POSIX; lock compatibility is tested against the open stateid; Not compared with the present file permissions.
- IO is also behaved in the same way. If the open fd and the lock/IO request are compatible, then the operation is allowed
if not, it will be failed with EPERM.