All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	linux-fsdevel@vger.kernel.org,
	overlayfs <linux-unionfs@vger.kernel.org>,
	LSM <linux-security-module@vger.kernel.org>,
	linux-kernel@vger.kernel.org,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Tyler Hicks <code@tyhicks.com>
Subject: Re: [PATCH 0/2] capability conversion fixes
Date: Wed, 20 Jan 2021 08:39:39 +0100	[thread overview]
Message-ID: <CAJfpegvY1ckAfR0c-RtzeBSaR8_dM2CV1MD_xJr=A6+MkSXi9A@mail.gmail.com> (raw)
In-Reply-To: <87y2go8wg9.fsf@x220.int.ebiederm.org>

On Tue, Jan 19, 2021 at 10:15 PM Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> Miklos Szeredi <mszeredi@redhat.com> writes:
>
> > It turns out overlayfs is actually okay wrt. mutliple conversions, because
> > it uses the right context for lower operations.  I.e. before calling
> > vfs_{set,get}xattr() on underlying fs, it overrides creds with that of the
> > mounter, so the current user ns will now match that of
> > overlay_sb->s_user_ns, meaning that the caps will be converted to just the
> > right format for the next layer
> >
> > OTOH ecryptfs, which is the only other one affected by commit 7c03e2cda4a5
> > ("vfs: move cap_convert_nscap() call into vfs_setxattr()") needs to be
> > fixed up, since it doesn't do the cap override thing that overlayfs does.
> >
> > I don't have an ecryptfs setup, so untested, but it's a fairly trivial
> > change.
> >
> > My other observation was that cap_inode_getsecurity() messes up conversion
> > of caps in more than one case.  This is independent of the overlayfs user
> > ns enablement but affects it as well.
> >
> > Maybe we can revisit the infrastructure improvements we discussed, but I
> > think these fixes are more appropriate for the current cycle.
>
> I mostly agree.  Fixing the bugs in a back-portable way is important.
>
> However we need to sort out the infrastructure, and implementation.
>
> As far as I can tell it is only the fact that overlayfs does not support
> the new mount api aka fs_context that allows this fix to work and be
> correct.
>
> I believe the new mount api would allow specifying a different userns
> thatn curent_user_ns for the overlay filesystem and that would break
> this.

This is a valid concern.   I'll add a WARN_ON() to make sure that
whenever this changes it doesn't go unnoticed.

Fixing it would also be easy:  just update creds->user_ns field to
that of sb->s_user_ns in ovl_fill_super().   For now I'll go with the
WARNING though, since this cannot be tested.

Thanks,
Miklos

      reply	other threads:[~2021-01-20  7:41 UTC|newest]

Thread overview: 27+ 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
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 19:37     ` kernel test robot
2021-01-20 21:08   ` 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 [this message]

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='CAJfpegvY1ckAfR0c-RtzeBSaR8_dM2CV1MD_xJr=A6+MkSXi9A@mail.gmail.com' \
    --to=miklos@szeredi.hu \
    --cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.