From: Tycho Andersen <tycho@tycho.ws>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Miklos Szeredi <miklos@szeredi.hu>,
containers@lists.linux-foundation.org,
linux-unionfs@vger.kernel.org,
David Howells <dhowells@redhat.com>,
Seth Forshee <seth.forshee@canonical.com>,
Eric Biederman <ebiederm@xmission.com>,
linux-fsdevel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH v2 2/3] fs: introduce uid/gid shifting bind mount
Date: Fri, 17 Jan 2020 13:19:40 -0800 [thread overview]
Message-ID: <20200117211940.GA22062@cisco> (raw)
In-Reply-To: <1579278342.3227.36.camel@HansenPartnership.com>
On Fri, Jan 17, 2020 at 08:25:42AM -0800, James Bottomley wrote:
> On Fri, 2020-01-17 at 09:44 -0600, Serge E. Hallyn wrote:
> > On Thu, Jan 16, 2020 at 08:29:33AM -0800, James Bottomley wrote:
> > I guess I figured we would have privileged task in the owning
> > namespace (presumably init_user_ns) mark a bind mount as shiftable
>
> Yes, that's what I've got today in the prototype. It mirrors the
> original shiftfs mechanism. However, I have also heard people say they
> want a permanent mark, like an xattr for this.
Please, no. mount() failures are already hard to reason about, I would
rather not add another temporary (or worse, permanent) non-obvious
failure mode.
What if we make shifted bind mounts always readonly? That will force
people to use an overlay (or something else) on top, but they probably
want to do that anyway so they can avoid tainting the original
container image with writes.
> > Oh - I consider the detail of whether we pass a userid or userns nsfd
> > as more of an implementation detail which we can hash out after the
> > more general shift-mount api is decided upon. Anyway, passing nsfds
> > just has a cool factor :)
>
> Well, yes, won't aruge on the cool factor-ness.
It's not just the cool factor: if you're doing this, it's presumably
because you want to use it with a container in a user namespace.
Specifying the same parameters twice leaves room for error, causing
CVEs and more work.
Tycho
next prev parent reply other threads:[~2020-01-17 21:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-04 20:39 [PATCH v2 0/3] introduce a uid/gid shifting bind mount James Bottomley
2020-01-04 20:39 ` [PATCH v2 1/3] fs: rethread notify_change to take a path instead of a dentry James Bottomley
2020-01-04 21:52 ` Amir Goldstein
2020-01-04 20:39 ` [PATCH v2 2/3] fs: introduce uid/gid shifting bind mount James Bottomley
2020-01-04 23:09 ` Amir Goldstein
2020-01-05 17:44 ` James Bottomley
2020-01-13 3:41 ` Serge E. Hallyn
2020-01-15 18:19 ` James Bottomley
2020-01-16 6:44 ` Serge E. Hallyn
2020-01-16 16:29 ` James Bottomley
2020-01-17 15:44 ` Serge E. Hallyn
2020-01-17 16:25 ` James Bottomley
2020-01-17 21:19 ` Tycho Andersen [this message]
2020-01-17 22:52 ` James Bottomley
2020-01-04 20:39 ` [PATCH v2 3/3] fs: expose shifting bind mount to userspace James Bottomley
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=20200117211940.GA22062@cisco \
--to=tycho@tycho.ws \
--cc=James.Bottomley@HansenPartnership.com \
--cc=containers@lists.linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=serge@hallyn.com \
--cc=seth.forshee@canonical.com \
--cc=viro@ZenIV.linux.org.uk \
/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).