bind mounting namespace inodes for unprivileged users
James Bottomley
James.Bottomley at HansenPartnership.com
Wed May 4 18:00:53 UTC 2016
On Wed, 2016-05-04 at 12:43 -0500, Eric W. Biederman wrote:
> James Bottomley <James.Bottomley at HansenPartnership.com> writes:
> > On Wed, 2016-05-04 at 09:38 -0500, Eric W. Biederman wrote:
> > > James Bottomley <James.Bottomley at HansenPartnership.com> writes:
> > > > So, does anyone have any strong (or even weak) opinions about
> > > > this before I start coding patches?
> > >
> > > The mount namespace is complex and getting it right is a pain in
> > > the rear. So adding yet another path and piece in to the
> > > existing complexity makes me cringe a little.
> >
> > Yes, well which is worse: having no way to bind unprivileged
> > containers without spawning a long running process or having a way
> > to bind them which may lead to unremovable files. Since I just use
> > sudo mount --bind anyway for my containers, I don't see the file
> > removal argument as too daunting.
>
> So far with setns support I haven't felt the need to bind mount
> containers. So I am not certain it is an either or choice.
>
> And of course the other side of the craziness is having a mount point
> on a filesystem makes that filesystem unmountable (except for lazy
> unmounts). So getting this wrong could affect clean shutdowns and
> reboots.
OK, I by this argument a little. It could be circumvented by having
the shutdown script remove all container bindings, though. This seems
to work
umount -t nsfs -a
> Which suggests it may be wise to limit this kind of thing
> to a tmpfs like /run/user/<uid>/.
>
> Mostly this is my way of say tread carefully because there be dragons
> here.
Understood. Even though fixing the pinned filesystem issue can be
done, I do agree that it makes the problem knottier.
James
More information about the Containers
mailing list