| Message ID | 20120719164452.2a1cf3bc@notabene.brown (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index eedd24d..15a718b 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2278,12 +2278,12 @@ static int nfs_open_permission_mask(int openflags) { int mask = 0; - if ((openflags & O_ACCMODE) != O_WRONLY) - mask |= MAY_READ; if ((openflags & O_ACCMODE) != O_RDONLY) mask |= MAY_WRITE; if (openflags & __FMODE_EXEC) mask |= MAY_EXEC; + else if ((openflags & O_ACCMODE) != O_WRONLY) + mask |= MAY_READ; return mask; }
[resending - with more current address for Trond :-] If there is a file on the server with permissions --x--x--x, then if I mount with NFSv3 I (as a non-root user) can run it. However if I mount with NFSv4 I cannot. This is with a sufficiently recent server kernel which fixes that server-side bug that caused a problem with this scenario. I think the bug was introduced by commit cd9a1c0e5ac68 NFSv4: Clean up nfs4_atomic_open which added a new call to nfs_may_open. The problem is that nfs_intent_set_file calls nfs_may_open passing intent.open.flags which contains O_RDONLY (i.e. 0). This is mapped to FMODE_READ before being passed to nfs_do_access. As I don't have read access, the exec fails. I can "fix it" with so we don't ask for READ permission if we are asking for EXEC permission. I suspect this may not be the right fix. I'm just presenting it to help focus on whether the problem seems to be. Is there a better way to fix this? Thanks, NeilBrown