On Fri, Apr 15, 2011 at 09:58:58PM -0300, Henrique de Moraes Holschuh wrote:
> 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.
Why would they? In both situations, /run, /run/lock and /run/shm
are all valid paths, be they real directories or symlinks. In the
postinst and init scripts, we've taken care to ensure that the old
and new paths are valid (and the same) in all circumstances.
> 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?).
On a host system, we can bind mount /run on /var/run and /run/lock
on /var/lock easily enough. We already do this if we can't create a
symlink. But a symlink works just as well, and is less likely to
result in inconsistency if the original directory is replaced with
another mount, unmounted, or otherwise changed (mount options).
Since it's just a pointer, it doesn't itself hold separate state,
which a bind mount does (given that they are independent vfsmounts).
On a guest system, we can never use bind mounts: rcS is either not
run, might run, or is replaced by other scripts, so we have to set
up the symlinks in postinst. If we used bind mounts in postinst
they would be lost and never recreated on system restart. Symlinks
are the only reliable choice here.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature