Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1586151 > unrolled thread

[PATCH] vfs: Partially revert addition of cred override in follow_automount()

Back to article view | Back to linux.kernel

Contents

  [PATCH] vfs: Partially revert addition of cred override in  follow_automount() David Howells <dhowells@redhat.com> - 2017-02-22 14:40 +0100
    Re: [PATCH] vfs: Partially revert addition of cred override in  follow_automount() Seth Forshee <seth.forshee@canonical.com> - 2017-02-22 16:20 +0100
    Re: [PATCH] vfs: Partially revert addition of cred override in follow_automount() David Howells <dhowells@redhat.com> - 2017-02-22 16:20 +0100

#1586151 — [PATCH] vfs: Partially revert addition of cred override in follow_automount()

The following commit:

	commit aeaa4a79ff6a5ed912b7362f206cf8576fca538b
	Author: Eric W. Biederman <ebiederm@xmission.com>
	Date:   Sat Jul 23 11:20:44 2016 -0500
	fs: Call d_automount with the filesystems creds

brackets the call to ->d_automount() with override_creds() and
revert_creds(), setting the initial credentials for use whilst
automounting.

This, however, breaks AFS as it's no longer able to access the calling
process's keyrings to read the destination on a mountpoint.  This has gone
unnoticed till now because, to this point, stat'ing or validating the inode
caused the body of the mountpoint to be read into the pagecache (so that we
could determine whether what we were looking at was really a mountpoint).

However, the page containing the mountpoint destination is merely *cached*
and not pinned.  If it gets discarded and we try to read it in d_automount,
we may fail because we have no authentication tokens available.

So, for the moment, revert the addition of override_creds() and
revert_creds() and their variable.

Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Seth Forshee <seth.forshee@canonical.com>
cc: "Eric W. Biederman" <ebiederm@xmission.com>
cc: Al Viro <viro@ZenIV.linux.org.uk>
---

 fs/namei.c |    3 ---
 1 file changed, 3 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index ad74877e1442..dff5cd3b556f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1100,7 +1100,6 @@ static int follow_automount(struct path *path, struct nameidata *nd,
 			    bool *need_mntput)
 {
 	struct vfsmount *mnt;
-	const struct cred *old_cred;
 	int err;
 
 	if (!path->dentry->d_op || !path->dentry->d_op->d_automount)
@@ -1129,9 +1128,7 @@ static int follow_automount(struct path *path, struct nameidata *nd,
 	if (nd->total_link_count >= 40)
 		return -ELOOP;
 
-	old_cred = override_creds(&init_cred);
 	mnt = path->dentry->d_op->d_automount(path);
-	revert_creds(old_cred);
 	if (IS_ERR(mnt)) {
 		/*
 		 * The filesystem is allowed to return -EISDIR here to indicate

[toc] | [next] | [standalone]

#1586247

On Wed, Feb 22, 2017 at 01:36:32PM +0000, David Howells wrote:
> The following commit:
> 
> 	commit aeaa4a79ff6a5ed912b7362f206cf8576fca538b
> 	Author: Eric W. Biederman <ebiederm@xmission.com>
> 	Date:   Sat Jul 23 11:20:44 2016 -0500
> 	fs: Call d_automount with the filesystems creds
> 
> brackets the call to ->d_automount() with override_creds() and
> revert_creds(), setting the initial credentials for use whilst
> automounting.
> 
> This, however, breaks AFS as it's no longer able to access the calling
> process's keyrings to read the destination on a mountpoint.  This has gone
> unnoticed till now because, to this point, stat'ing or validating the inode
> caused the body of the mountpoint to be read into the pagecache (so that we
> could determine whether what we were looking at was really a mountpoint).
> 
> However, the page containing the mountpoint destination is merely *cached*
> and not pinned.  If it gets discarded and we try to read it in d_automount,
> we may fail because we have no authentication tokens available.
> 
> So, for the moment, revert the addition of override_creds() and
> revert_creds() and their variable.
> 
> Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Seth Forshee <seth.forshee@canonical.com>
> cc: "Eric W. Biederman" <ebiederm@xmission.com>
> cc: Al Viro <viro@ZenIV.linux.org.uk>

Eric's already applied a patch that should fix this problem. As far as I
know it's only been tested against NFS though, so you might want to test
that it also fixes the issue with AFS.

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=93faccbbfa958a9668d3ab4e30f38dd205cee8d8

Thanks,
Seth

[toc] | [prev] | [next] | [standalone]

#1586254 — Re: [PATCH] vfs: Partially revert addition of cred override in follow_automount()

David Howells <dhowells@redhat.com> wrote:

> The following commit:
> 
> 	commit aeaa4a79ff6a5ed912b7362f206cf8576fca538b
> 	Author: Eric W. Biederman <ebiederm@xmission.com>
> 	Date:   Sat Jul 23 11:20:44 2016 -0500
> 	fs: Call d_automount with the filesystems creds
> 
> brackets the call to ->d_automount() with override_creds() and
> revert_creds(), setting the initial credentials for use whilst
> automounting.
> 
> This, however, breaks AFS as it's no longer able to access the calling
> process's keyrings to read the destination on a mountpoint.  This has gone
> unnoticed till now because, to this point, stat'ing or validating the inode
> caused the body of the mountpoint to be read into the pagecache (so that we
> could determine whether what we were looking at was really a mountpoint).
> 
> However, the page containing the mountpoint destination is merely *cached*
> and not pinned.  If it gets discarded and we try to read it in d_automount,
> we may fail because we have no authentication tokens available.
> 
> So, for the moment, revert the addition of override_creds() and
> revert_creds() and their variable.
> 
> Fixes: aeaa4a79ff6a ("fs: Call d_automount with the filesystems creds")
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Seth Forshee <seth.forshee@canonical.com>
> cc: "Eric W. Biederman" <ebiederm@xmission.com>
> cc: Al Viro <viro@ZenIV.linux.org.uk>

This is also resolved by:

	https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-next&id=93faccbbfa958a9668d3ab4e30f38dd205cee8d8

David

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web