linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] vfs: remove unneeded permission check from path_init
@ 2012-12-11 13:56 Jeff Layton
  2012-12-12 18:40 ` Al Viro
  0 siblings, 1 reply; 2+ messages in thread
From: Jeff Layton @ 2012-12-11 13:56 UTC (permalink / raw)
  To: viro; +Cc: linux-fsdevel, linux-kernel, dwysocha

When path_init is called with a valid dfd, that code checks permissions
on the open directory fd and returns an error if the check fails. This
permission check is redundant, however.

Both callers of path_init immediately call link_path_walk afterward. The
first thing that link_path_walk does is to check for exec permissions
at the starting point of the path walk.

In most cases, these checks are very quick, but when the dfd is for a
file on a NFS mount with the actimeo=0, each permission check goes
out onto the wire. The result is 2 identical ACCESS calls.

Given that these codepaths are fairly "hot", I think it makes sense to
eliminate the permission check in path_init and simply assume that the
caller will eventually check the permissions before proceeding.

Reported-by: Dave Wysochanski <dwysocha@redhat.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
 fs/namei.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 40d864a..deefbc3 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1894,6 +1894,7 @@ static int path_init(int dfd, const char *name, unsigned int flags,
 			get_fs_pwd(current->fs, &nd->path);
 		}
 	} else {
+		/* Caller must check execute permissions on the starting path component */
 		struct fd f = fdget_raw(dfd);
 		struct dentry *dentry;
 
@@ -1907,12 +1908,6 @@ static int path_init(int dfd, const char *name, unsigned int flags,
 				fdput(f);
 				return -ENOTDIR;
 			}
-
-			retval = inode_permission(dentry->d_inode, MAY_EXEC);
-			if (retval) {
-				fdput(f);
-				return retval;
-			}
 		}
 
 		nd->path = f.file->f_path;
-- 
1.7.11.7


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] vfs: remove unneeded permission check from path_init
  2012-12-11 13:56 [PATCH] vfs: remove unneeded permission check from path_init Jeff Layton
@ 2012-12-12 18:40 ` Al Viro
  0 siblings, 0 replies; 2+ messages in thread
From: Al Viro @ 2012-12-12 18:40 UTC (permalink / raw)
  To: Jeff Layton; +Cc: linux-fsdevel, linux-kernel, dwysocha

On Tue, Dec 11, 2012 at 08:56:16AM -0500, Jeff Layton wrote:
> When path_init is called with a valid dfd, that code checks permissions
> on the open directory fd and returns an error if the check fails. This
> permission check is redundant, however.
> 
> Both callers of path_init immediately call link_path_walk afterward. The
> first thing that link_path_walk does is to check for exec permissions
> at the starting point of the path walk.
> 
> In most cases, these checks are very quick, but when the dfd is for a
> file on a NFS mount with the actimeo=0, each permission check goes
> out onto the wire. The result is 2 identical ACCESS calls.
> 
> Given that these codepaths are fairly "hot", I think it makes sense to
> eliminate the permission check in path_init and simply assume that the
> caller will eventually check the permissions before proceeding.

Applied, with one modification to commit message - the second paragraph
replaced with

Both callers of path_init immediately call link_path_walk afterward. The
first thing that link_path_walk does for pathnames that do not consist
only of slashes is to check for exec permissions at the starting point of
the path walk.  And this check in path_init() is on the path taken only
when *name != '/' && *name != '\0'.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-12-12 18:40 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-11 13:56 [PATCH] vfs: remove unneeded permission check from path_init Jeff Layton
2012-12-12 18:40 ` Al Viro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).