Adam, which version of the kernel are you using? This is a big deal if a user in the vserver can knock the whole box offline... especially for those of us with less-trusted users playing with root in the vserver.
THanks! On Mon, 16 Dec 2002, Adam H. Pendleton wrote: > At 10:44 12/16/2002, you wrote: > >On Mon, 16 Dec 2002, Adam H. Pendleton wrote: > > > The `vserver <name> build` operation worked great, with one problem [..] > > > > > > A `vserver <name> stop` operation runs [..] `/etc/init.d/network stop`, > > > which kills all network connectivity to the box!! > > > >This should fail in a vserver (or have you given the vserver more > >capabilites like CAP_NET_ADMIN to allow it access to the kernel > >networking interfaces that are otherwise denied)? > > No additional capabilities were given to the vserver, at least not by my > hand. :) The /etc/init.d/network script calls /sbin/ifdown to stop > interfaces. The interface is passed the name of the device (e.g. eth0), > not an IP, so when executing `vserver <name> stop` the RedHat init lines go > by, until I see > > blah blah blah [OK] > Stopping interface eth0... > > and then it's off-line. > > > > > I assume the only way to prevent this is to delete/modify /etc/init.d/ > > > >Best to delete them (or rather the runlevel sysvinit symlinks to them). > >My Debian install script currently does `update-rc.d foo remove' on: > > > > klogd hwclock.sh setserial urandom networking umountfs halt reboot > > > >(Anything related to hardware or kernel management which is going to fail > >anyway just sitting there and timing out). > > I will be sure to delete them, but not because they're timing out. :) > > > > -Paul > >-- > >Nottingham, GB >
