Re: bind mounting namespace inodes for unprivileged users

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2016-05-04 at 12:43 -0500, Eric W. Biederman wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> > On Wed, 2016-05-04 at 09:38 -0500, Eric W. Biederman wrote:
> > > James Bottomley <James.Bottomley@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