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
