ACK/Cmnt: [SRU][K][PATCH] UBUNTU: [SAUCE] shiftfs: fix -EOVERFLOW inside the container

Aleksandr Mikhalitsyn aleksandr.mikhalitsyn at canonical.com
Tue Jan 31 16:53:51 UTC 2023


On Tue, Jan 31, 2023 at 5:49 PM Andrea Righi <andrea.righi at canonical.com> wrote:
>
> On Tue, Jan 31, 2023 at 05:11:48PM +0100, Alexander Mikhalitsyn wrote:
> > BugLink: https://bugs.launchpad.net/bugs/1990849
> >
> > We haven't supported idmapped layers with shiftfs and moreover, that makes
> > no sense. Once lower fs support idmapped mounts when shiftfs is not needed.
> >
> > Starting from linux-image-5.15.0-48-generic users started seeing EOVERFLOW
> > errors from the userspace side on a trivial fs operations inside the containers.
> >
> > This is caused by patches ("fs: tweak fsuidgid_has_mapping()"),
> > ("fs: support mapped mounts of mapped filesystems"). These patches extends
> > and enables idmapped mounts support in Ubuntu kernel, but the problem is
> > that shiftfs was not properly ported.
> >
> > See also:
> > ("namei: prepare for idmapped mounts")
> > https://lore.kernel.org/all/20210121131959.646623-15-christian.brauner@ubuntu.com/
> > ("overlayfs: do not mount on top of idmapped mounts")
> > https://lore.kernel.org/all/20210121131959.646623-29-christian.brauner@ubuntu.com/
> > as a reference.
> >
> > This patch should be appied on top of kinetic/master-next and based on the
> > changes by Andrea Righi 4c934edc66 ("UBUNTU: SAUCE: shiftfs: always rely on init_user_ns")
> >
> > This commit together with 4c934edc66 ("UBUNTU: SAUCE: shiftfs: always rely on init_user_ns")
> > have to be ported to the jammy tree too.
> >
> > Fixes: d347e71d2c0 ("UBUNTU: [SAUCE] shiftfs: support kernel 5.15")
> > Reported-by: Thomas Parrott <thomas.parrott at canonical.com>
> > Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn at canonical.com>
>
> Makes sense to me. Thanks for looking at this. I'll also apply this to
> lunar/linux and lunar/linux-unstable.

Thanks! What about jammy/linux? In the jammy branch we have shiftfs
totally broken right now.

Kind regards,
Alex

>
> In the meantime:
>
> Acked-by: Andrea Righi <andrea.righi at canonical.com>
>
> > ---
> >  fs/shiftfs.c | 16 +++++++++++++---
> >  1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/fs/shiftfs.c b/fs/shiftfs.c
> > index a5338dc6290c..c7e8b88915b1 100644
> > --- a/fs/shiftfs.c
> > +++ b/fs/shiftfs.c
> > @@ -632,10 +632,10 @@ static int shiftfs_rename(struct user_namespace *ns,
> >       struct inode *loweri_dir_old = lowerd_dir_old->d_inode,
> >                    *loweri_dir_new = lowerd_dir_new->d_inode;
> >       struct renamedata rd = {
> > -             .old_mnt_userns = ns,
> > +             .old_mnt_userns = &init_user_ns,
> >               .old_dir        = loweri_dir_old,
> >               .old_dentry     = lowerd_old,
> > -             .new_mnt_userns = ns,
> > +             .new_mnt_userns = &init_user_ns,
> >               .new_dir        = loweri_dir_new,
> >               .new_dentry     = lowerd_new,
> >       };
> > @@ -972,7 +972,7 @@ shiftfs_posix_acl_xattr_set(const struct xattr_handler *handler,
> >               return -EOPNOTSUPP;
> >       if (handler->flags == ACL_TYPE_DEFAULT && !S_ISDIR(inode->i_mode))
> >               return value ? -EACCES : 0;
> > -     if (!inode_owner_or_capable(ns, inode))
> > +     if (!inode_owner_or_capable(&init_user_ns, inode))
> >               return -EPERM;
> >
> >       if (value) {
> > @@ -2016,6 +2016,16 @@ static int shiftfs_fill_super(struct super_block *sb, void *raw_data,
> >               goto out_put_path;
> >       }
> >
> > +     /*
> > +      * It makes no sense to handle idmapped layers from shiftfs.
> > +      * And we didn't support it properly anyway.
> > +      */
> > +     if (is_idmapped_mnt(path.mnt)) {
> > +             err = -EINVAL;
> > +             pr_err("idmapped layers are currently not supported\n");
> > +             goto out_put_path;
> > +     }
> > +
> >       sb->s_flags |= SB_POSIXACL;
> >
> >       if (sbinfo->mark) {
> > --
> > 2.34.1
> >
> >
> > --
> > kernel-team mailing list
> > kernel-team at lists.ubuntu.com
> > https://lists.ubuntu.com/mailman/listinfo/kernel-team



More information about the kernel-team mailing list