On Fri, Nov 15, 2024 at 08:34:07AM -0500, Theodore Ts'o wrote:
> On Mon, Nov 11, 2024 at 09:52:07AM +0100, Christian Brauner wrote:
>
> > behavior would be well-specified so the patch changed that quite some
> > time ago.
> >
> > Backporting this to older LTS kernels isn't difficult. We just need
> > custom patches for the LTS kernels but they should all be very simple.
> >
> > Alternatively, you can just ignore the test on older kernels.
>
> Well, what the custom patch to look like wasn't obvious to me, but
> that's because I'm not sufficiently familiar with the id mapping code.
>
> So I'll just ignore the test on older kernels. If someone wants to
> create the custom patch, I'll revert the versioned exclude for
> {kvm,gce}-xfsteests.
>
> Thanks,
>
> - Ted
>
Hi,
We did notice this as well during our internal testing. I'm unfamiliar
with the code but after spending some time I came up with the
following patch that did fix it for us (it's a rough patch, might not
apply cleanly to any stable kernel). Again, I'm not 100% sure if this is
the right place to patch it but if it looks good to peopel more familiar with
the area then I can try to send the backports to the stable.
---
fs/namespace.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/namespace.c b/fs/namespace.c
index 7906c5327f4f..368a60e48861 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3995,6 +3995,12 @@ static int can_idmap_mount(const struct mount_kattr *kattr, struct mount *mnt)
if (!kattr->mnt_idmap)
return 0;
+ /* Don't allow idmaps with no mapping defined */
+ if (kattr->mnt_userns->uid_map.nr_extents == 0 ||
+ kattr->mnt_userns->gid_map.nr_extents == 0)
+ return -EINVAL;
+
+
/*
* Creating an idmapped mount with the filesystem wide idmapping
* doesn't make sense so block that. We don't allow mushy semantics.
--
2.43.0
Regards,
ojaswin
