[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOssrKd04WaFjM1=qyUVnxwM9k_4Mc=OvvuCeN9HvYJnq91wWA@mail.gmail.com>
Date: Mon, 25 Jan 2021 14:46:01 +0100
From: Miklos Szeredi <mszeredi@...hat.com>
To: Tyler Hicks <code@...icks.com>
Cc: "Eric W . Biederman" <ebiederm@...ssion.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
overlayfs <linux-unionfs@...r.kernel.org>,
linux-security-module@...r.kernel.org,
lkml <linux-kernel@...r.kernel.org>,
"Serge E . Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability
On Mon, Jan 25, 2021 at 2:25 PM Miklos Szeredi <mszeredi@...hat.com> wrote:
>
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks <code@...icks.com> wrote:
> >
> > On 2021-01-19 17:22:03, Miklos Szeredi wrote:
> > > Prior to commit 7c03e2cda4a5 ("vfs: move cap_convert_nscap() call into
> > > vfs_setxattr()") the translation of nscap->rootid did not take stacked
> > > filesystems (overlayfs and ecryptfs) into account.
> > >
> > > That patch fixed the overlay case, but made the ecryptfs case worse.
> >
> > Thanks for sending a fix!
> >
> > I know that you don't have an eCryptfs setup to test with but I'm at a
> > loss about how to test this from the userns/fscaps side of things. Do
> > you have a sequence of unshare/setcap/getcap commands that I can run on
> > a file inside of an eCryptfs mount to verify that the bug exists after
> > 7c03e2cda4a5 and then again to verify that this patch fixes the bug?
>
> You need two terminals:
> $ = <USER>
> # = root
>
> $ unshare -Um
> $ echo $$
> <PID>
> # echo "0 1000 1" > uid_map
NOTE: <USER> is assumed to have uid=1000, so this and following
"1000" values need to be fixed up if it's not the case.
Thanks,
Miklos
Powered by blists - more mailing lists