On Thu, 7 Apr 2022 at 13:23, Christian Brauner <brauner@xxxxxxxxxx> wrote: > > Make the two places where lookup helpers can be called either on lower > or upper layers take the mount's idmapping into account. To this end we > pass down the mount in struct ovl_lookup_data. It can later also be used > to construct struct path for various other helpers. This is needed to > support idmapped base layers with overlay. > > Cc: <linux-unionfs@xxxxxxxxxxxxxxx> > Tested-by: Giuseppe Scrivano <gscrivan@xxxxxxxxxx> > Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > Signed-off-by: Christian Brauner (Microsoft) <brauner@xxxxxxxxxx> > --- > /* v2 */ > unchanged > > /* v3 */ > unchanged > > /* v4 */ > - Vivek Goyal <vgoyal@xxxxxxxxxx>: > - s/ovl_upper_idmap()/ovl_upper_mnt_userns()/g > > /* v5 */ > unchanged > --- > fs/overlayfs/export.c | 3 ++- > fs/overlayfs/namei.c | 14 ++++++++------ > fs/overlayfs/readdir.c | 10 +++++----- > 3 files changed, 15 insertions(+), 12 deletions(-) > > diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c > index ebde05c9cf62..5acf353d160b 100644 > --- a/fs/overlayfs/export.c > +++ b/fs/overlayfs/export.c > @@ -391,7 +391,8 @@ static struct dentry *ovl_lookup_real_one(struct dentry *connected, > * pointer because we hold no lock on the real dentry. > */ > take_dentry_name_snapshot(&name, real); > - this = lookup_one_len(name.name.name, connected, name.name.len); > + this = lookup_one(mnt_user_ns(layer->mnt), name.name.name, > + connected, name.name.len); This one is tricky. It's doing a lookup on overlay, so messing with the underlying mnt_userns is definitely wrong. Is the mnt_userns needed for permission checking? Possibly in that case the permission checking needs to be skipped altogether, since it's doing an fh -> dentry lookup which should succeed regardless of caller's caps. Thanks, Miklos
