[v2,02/19] exportfs: support idmapped mounts

Commit Message

Christian Brauner March 30, 2022, 10:23 a.m. UTC

Make the two locations where exportfs helpers check permission to lookup
a given inode idmapped mount aware by switching it to the lookup_one()
helper. This is a bugfix for the open_by_handle_at() system call which
doesn't take idmapped mounts into account currently. It's not tied to a
specific commit so we'll just Cc stable.

In addition this is required to support idmapped base layers in overlay.
The overlay filesystem uses exportfs to encode and decode file handles
for its index=on mount option and when nfs_export=on.

Cc: <[e-mail]>
Cc: <[e-mail]>
Tested-by: Giuseppe Scrivano <[e-mail]>
Reviewed-by: Amir Goldstein <[e-mail]>
Signed-off-by: Christian Brauner (Microsoft) <[e-mail]>
---
/* v2 */
unchanged
---
 fs/exportfs/expfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Christoph Hellwig March 30, 2022, 3:26 p.m. UTC | #1

On Wed, Mar 30, 2022 at 12:23:50PM +0200, Christian Brauner wrote:
> Make the two locations where exportfs helpers check permission to lookup
> a given inode idmapped mount aware by switching it to the lookup_one()
> helper. This is a bugfix for the open_by_handle_at() system call which
> doesn't take idmapped mounts into account currently. It's not tied to a
> specific commit so we'll just Cc stable.
> 
> In addition this is required to support idmapped base layers in overlay.
> The overlay filesystem uses exportfs to encode and decode file handles
> for its index=on mount option and when nfs_export=on.

This probably wants a Fixes tag, as without it NFS exporting idmapped
file will give slightly unexpected results.

Otherwise looks fine:

Reviewed-by: Christoph Hellwig <[e-mail]>

Christian Brauner March 30, 2022, 4:04 p.m. UTC | #2

On Wed, Mar 30, 2022 at 05:26:35PM +0200, Christoph Hellwig wrote:
> On Wed, Mar 30, 2022 at 12:23:50PM +0200, Christian Brauner wrote:
> > Make the two locations where exportfs helpers check permission to lookup
> > a given inode idmapped mount aware by switching it to the lookup_one()
> > helper. This is a bugfix for the open_by_handle_at() system call which
> > doesn't take idmapped mounts into account currently. It's not tied to a
> > specific commit so we'll just Cc stable.
> > 
> > In addition this is required to support idmapped base layers in overlay.
> > The overlay filesystem uses exportfs to encode and decode file handles
> > for its index=on mount option and when nfs_export=on.
> 
> This probably wants a Fixes tag, as without it NFS exporting idmapped
> file will give slightly unexpected results.

I made it so that the nfs kernel server will refuse to be mounted on top
of idmapped mounts in check_export() similar to what I did originally do
for overlayfs. It's unclear what the Fixes: tag would be so I'll just Cc
stable.

> 
> Otherwise looks fine:
> 
> Reviewed-by: Christoph Hellwig <[e-mail]>

Thanks!

Christoph Hellwig March 30, 2022, 4:08 p.m. UTC | #3

On Wed, Mar 30, 2022 at 06:04:48PM +0200, Christian Brauner wrote:
> > This probably wants a Fixes tag, as without it NFS exporting idmapped
> > file will give slightly unexpected results.
> 
> I made it so that the nfs kernel server will refuse to be mounted on top
> of idmapped mounts in check_export() similar to what I did originally do
> for overlayfs. It's unclear what the Fixes: tag would be so I'll just Cc
> stable.

So knfsd is fine, and the handle_to_name syscall doesn't ever do the
equivalent of the subtree check.  So with that we probably don't need
a Fixes tag - sorry for the noise.

Christian Brauner March 30, 2022, 4:11 p.m. UTC | #4

On Wed, Mar 30, 2022 at 06:08:16PM +0200, Christoph Hellwig wrote:
> On Wed, Mar 30, 2022 at 06:04:48PM +0200, Christian Brauner wrote:
> > > This probably wants a Fixes tag, as without it NFS exporting idmapped
> > > file will give slightly unexpected results.
> > 
> > I made it so that the nfs kernel server will refuse to be mounted on top
> > of idmapped mounts in check_export() similar to what I did originally do
> > for overlayfs. It's unclear what the Fixes: tag would be so I'll just Cc
> > stable.
> 
> So knfsd is fine, and the handle_to_name syscall doesn't ever do the
> equivalent of the subtree check.  So with that we probably don't need
> a Fixes tag - sorry for the noise.

No worries, thank you for taking a close look!

Patch

diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
index 0106eba46d5a..3ef80d000e13 100644
--- a/fs/exportfs/expfs.c
+++ b/fs/exportfs/expfs.c
@@ -145,7 +145,7 @@  static struct dentry *reconnect_one(struct vfsmount *mnt,
 	if (err)
 		goto out_err;
 	dprintk("%s: found name: %s\n", __func__, nbuf);
-	tmp = lookup_one_len_unlocked(nbuf, parent, strlen(nbuf));
+	tmp = lookup_one_unlocked(mnt_user_ns(mnt), nbuf, parent, strlen(nbuf));
 	if (IS_ERR(tmp)) {
 		dprintk("%s: lookup failed: %d\n", __func__, PTR_ERR(tmp));
 		err = PTR_ERR(tmp);
@@ -525,7 +525,8 @@  exportfs_decode_fh_raw(struct vfsmount *mnt, struct fid *fid, int fh_len,
 		}
 
 		inode_lock(target_dir->d_inode);
-		nresult = lookup_one_len(nbuf, target_dir, strlen(nbuf));
+		nresult = lookup_one(mnt_user_ns(mnt), nbuf,
+				     target_dir, strlen(nbuf));
 		if (!IS_ERR(nresult)) {
 			if (unlikely(nresult->d_inode != result->d_inode)) {
 				dput(nresult);