Re: Does overlay driver work if built in to the kernel?

From: Amir Goldstein <amir73il@gmail.com>
To: "Jie, Keyon" <keyon.jie@intel.com>
Cc: Keyon Jie <yang.jie@linux.intel.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: Does overlay driver work if built in to the kernel?
Date: Wed, 21 Sep 2022 20:41:57 +0300	[thread overview]
Message-ID: <CAOQ4uxjFeV9CP7xLrCsWNMbZ3F1CKcea-Tr7Wnx95YLpkvUkzw@mail.gmail.com> (raw)
In-Reply-To: <MWHPR11MB191913944274BE566826A4BEF14F9@MWHPR11MB1919.namprd11.prod.outlook.com>

On Wed, Sep 21, 2022 at 5:48 PM Jie, Keyon <keyon.jie@intel.com> wrote:
>
>
> > -----Original Message-----
> > From: Amir Goldstein <amir73il@gmail.com>
> > Sent: Tuesday, September 20, 2022 11:50 PM
> > To: Keyon Jie <yang.jie@linux.intel.com>
> > Cc: Miklos Szeredi <miklos@szeredi.hu>; overlayfs <linux-
> > unionfs@vger.kernel.org>; Jie, Keyon <keyon.jie@intel.com>
> > Subject: Re: Does overlay driver work if built in to the kernel?
> >
> > On Wed, Sep 21, 2022 at 3:32 AM Keyon Jie <yang.jie@linux.intel.com>
> > wrote:
> > >
> > > Hi all,
> > >
> > > I am new to the overlayfs, I am hitting issues to make kernel modules
> > > work in a container environment where the Kubernetes feature really
> > need
> > > the overlayfs support.
> > >
> > > I figured out to make overlay driver built-in to the VM kernel (and then
> > > shared to the container), but looks like the Kubernetes always fail when
> > > trying to create overlayfs mounts, with errors like 'permission denied'.
> > >
> >
> > Usually, you want to look at the kernel log to see the reason for failure.
> > That is likely because the container is "unprivileged"
> > meaning not using the same uid 0 as the host.
> >
> > Don't know which kernel you are running, but overlayfs can be mounted
> > inside unprivileged container since kernel v5.11:
> >
> > https://lore.kernel.org/linux-
> > fsdevel/20201217142025.GB1236412@miu.piliscsaba.redhat.com/
>
> Thank you Amir.
> I am using v5.10 kernel, so looks I can try to backport some of the patches and try it again.
> I assume take the 10-commits series from Miklos should be enough?
>       vfs: move cap_convert_nscap() call into vfs_setxattr()
>       vfs: verify source area in vfs_dedupe_file_range_one()
>       ovl: check privs before decoding file handle
>       ovl: make ioctl() safe
>       ovl: simplify file splice
>       ovl: user xattr
>       ovl: do not fail when setting origin xattr
>       ovl: do not fail because of O_NOATIME
>       ovl: do not get metacopy for userxattr
>       ovl: unprivieged mounts
> https://lore.kernel.org/linux-fsdevel/1725e01a-4d4d-aecb-bad6-54aa220b4cd2@i-love.sakura.ne.jp/T/
>

Not sure you can try.
There may be other bug fixes that need backporting.
It is not recommended to backport such a feature by yourself.
You would be much better off taking or build a newer LTS kernel (e.g. 5.15.y)

Thanks,
Amir.