linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tyler Hicks <code@tyhicks.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: "Eric W . Biederman" <ebiederm@xmission.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-security-module@vger.kernel.org,
	lkml <linux-kernel@vger.kernel.org>,
	"Serge E . Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability
Date: Mon, 25 Jan 2021 19:52:59 -0600	[thread overview]
Message-ID: <20210126015259.GC81247@sequoia> (raw)
In-Reply-To: <CAOssrKd-P=4n-nzhjnvnChbCkcrAaLC=NjmCTDRHtzRtzJaU-g@mail.gmail.com>

On 2021-01-25 14:25:38, Miklos Szeredi wrote:
> On Fri, Jan 22, 2021 at 7:31 PM Tyler Hicks <code@tyhicks.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
> # cp uid_map gid_map
> # echo 1000 2000 1 >> uid_map
> # echo 2000 3000 1 >> uid_map
> # cat uid_map > /proc/<PID>/uid_map
> # cat gid_map > /proc/<PID>/gid_map
> $ mkdir ~/tmp ~/mnt
> $ mount -t tmpfs tmpfs ~/tmp
> $ pwd
> /home/<USER>
> # nsenter -t <PID> -m
> # [setup ecryptfs on /home/<USER>/mnt using /home/<USER>/tmp]
> $ cd ~/mnt
> $ touch test
> $ /sbin/setcap -n 1000 cap_dac_override+eip test
> $ /sbin/getcap -n test
> test = cap_dac_override+eip [rootid=1000]
> 
> Without the patch, I'm thinking that it will do a double translate and
> end up with rootid=2000 in the user namespace, but I might well have
> messed it up...
> 
> Let me know how this goes.

Spot-on instructions. Thank you for taking the time to provide the
steps.

I was able to repro the bug and verify the fix. The change visually
looks good to me and it passed through the eCryptfs regression tests.

I've pushed it to the eCryptfs next branch and I plan to submit it to
Linus on Thursday. Thanks again!

Tyler

> 
> Thanks,
> Miklos
> 

  parent reply	other threads:[~2021-01-26  5:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-19 16:22 [PATCH 0/2] capability conversion fixes Miklos Szeredi
2021-01-19 16:22 ` [PATCH 1/2] ecryptfs: fix uid translation for setxattr on security.capability Miklos Szeredi
2021-01-19 21:06   ` Eric W. Biederman
2021-01-20  7:52     ` Miklos Szeredi
2021-01-22 16:04       ` Tyler Hicks
2021-01-22 18:31   ` Tyler Hicks
2021-01-25 13:25     ` Miklos Szeredi
2021-01-25 13:46       ` Miklos Szeredi
2021-01-26  1:52       ` Tyler Hicks [this message]
2021-01-19 16:22 ` [PATCH 2/2] security.capability: fix conversions on getxattr Miklos Szeredi
2021-01-20  1:34   ` Eric W. Biederman
2021-01-20  7:58     ` Miklos Szeredi
2021-01-28 16:58     ` Serge E. Hallyn
2021-01-28 20:19       ` Eric W. Biederman
2021-01-28 20:38         ` Miklos Szeredi
2021-01-28 20:49           ` Eric W. Biederman
     [not found]         ` <20210129154839.GC1130@mail.hallyn.com>
2021-01-29 22:55           ` Eric W. Biederman
2021-01-30  2:06             ` Serge E. Hallyn
2021-01-31 18:14               ` Eric W. Biederman
     [not found]       ` <CAJfpegt34fO8tUw8R2_ZxxKHBdBO_-quf+-f3N8aZmS=1oRdvQ@mail.gmail.com>
     [not found]         ` <20210129153807.GA1130@mail.hallyn.com>
2021-01-29 23:11           ` Eric W. Biederman
2021-01-30  2:04             ` Serge E. Hallyn
2021-01-20 19:37   ` kernel test robot
2021-01-20 21:08   ` kernel test robot
2021-01-19 21:10 ` [PATCH 0/2] capability conversion fixes Eric W. Biederman
2021-01-20  7:39   ` Miklos Szeredi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210126015259.GC81247@sequoia \
    --to=code@tyhicks.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).