[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /run support for wheezy: final (I hope) call for testing

On Sat, 16 Apr 2011, Roger Leigh wrote:
> On Fri, Apr 15, 2011 at 08:59:01PM -0300, Henrique de Moraes Holschuh wrote:
> > On Fri, 15 Apr 2011, Roger Leigh wrote:
> > > { find var/run/  ! -type d -print0; \
> > >   find var/lock/ ! -type d -print0; } | xargs -0r $_CHROOT_SH rm
> > > 
> > > I'm afraid this will need fixing in util-vserver(?) though.  We can't
> > > work around this in initscripts postinst, I'm afraid, since it worked
> > > correctly, and this happened after the migration.
> > 
> > The proper fix would be to use bind mounts, or always use multiple tmpfs
> > (which is safer, anyway).
> We have now fixed this issue by never moving /var/run or /var/lock
> in postinst.  In the case of a chroot/vserver, we simply create a
> symlink from the new location (/run) to the old (/var/run) so that
> both paths are functional.  In consequence, /var/run and /var/lock
> will remain directories in a vserver environment.

Now, scripts that work outside of vservers and want /run might croak when
run inside a vserver.

Symlinks in system path components REALLY are best avoided.

We CAN afford four tmpfs in the first place, */run and */lock can be very
strictly limited (e.g. 10MB-100MB), so even in a bug/local attack scenario,
they are not a large problem.  And that's only needed if bind mounts are
really such an horrible alternative in the first place (are they?).

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: