On Tue, 2019-04-09 at 09:26 +0000, Diego Santa Cruz wrote:
> Hello,
>
> I have encountered a problem with access(dir, W_OK) calls and world
> writable directories on NFS which are not owner by the calling user.
> The call returns EACCES, even though the user can create files in the
> directory. I use NFSv3, but this may also impact other NFS versions.
>
> Test case, on an NFSv3 mounted directory is:
> 1. Create world writable directory as root: sudo mkdir -m 777 testdir
> 2. Test that normal user can create a file: rm -f testdir/foo &&
> touch testdir/foo
> 3. Test for writability with access: strace -o log test -w testdir &&
> echo PASS || echo FAIL
> 4. Checking the strace log shows that access("testdir", W_OK) fails
> with EACCES
>
> I am using the linux-intel kernel 4.19.13, but I traced this to
> commit ecbb903c56745 in linux master (NFS: Be more careful about
> mapping file permissions), that went into kernel 4.13. The test works
> fine in earlier kernels. The problem does not always show up on
> directories owned by the calling user, but it may be due to attribute
> caching or similar.
>
> I am not very NFS savvy but as far as I understand the commit above
> changed the tests in nfs_access_calc_mask() from "any bit in mask is
> set" to "all bits in mask are set". The mask for writable directories
> is ACCESS_MODIFY, ACCESS_EXTEND, ACCESS_DELETE but from what I see in
> a network capture the response from the NFS server is lacking the
> ACCESS_DELETE bit.
>
> The attached patch reverts the tests in nfs_access_calc_mask() to
> "any bit in mask is set", which makes the test case work again, but I
> am not sure it is entirely correct to change all the tests, or if it
> would be more appropriate to drop ACCESS_DELETE from the
> NFS_DIR_MAY_WRITE mask. The patch applies cleanly on current linux
> master.
>
> I checked the NFSv3 and NFSv4 RFCs, but it is not clear to me if
> ACCESS_DELETE is for the directory itself or its children. In any
> case my NFS server is omitting ACCESS_DELETE from the response (it is
> a Synology running Linux kernel 3.10.105).
>
The ACCESS_DELETE bit applies _only_ to directories, so if it is
missing in the reply from your server for a directory with POSIX 777
permissions, then you should talk to the server vendor.
As far as I can see, the current code is correct. If you do not have
the ACCESS_DELETE bit set on your directory, then the server is telling
the client that your process does not have full write permissions to
that directory in accordance with the POSIX spec.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@xxxxxxxxxxxxxxx
