From: Jonathan Sambrook (jonathan.sambrook_at_dsvr.co.uk)
Date: Thu 20 Feb 2003 - 18:40:27 GMT
At 18:16 on Thu 20/02/03, herbert_at_13thfloor.at masquerading as 'Herbert Poetzl' wrote:
> On Thu, Feb 20, 2003 at 04:26:19PM +0000, Jonathan Sambrook wrote:
> > I'm looking at the ctx patch for DSVR to see how we could integrate it
> > into our operation (see http://www.dsvr.co.uk).
> hmm, maybe you could elaborate a little bit
> on your plans regarding the "operation"
We instigated FreeVSD over four years ago, and are looking at using the
s_context kernel patch on our boxes.
> > We'd like vserver users to be as ignorant of their vserver-ness as
> > possible, hence cloaking /proc/self/status.
> but what about the other 10 or 20 indices for
> a virtual server environment? (e.g. mknod, ethernet
> etc ...) or do you give all capabilities?
You know you're in a virtual server, 'cos that's what you've paid for,
but if someone gains unauthorised access, they should be given as little
info as possible,
> > But for investigating/debugging/hacking-on-vserver purposes, this
> > cloaking should be sysctl-able.
> > The ctx sysctl should itself be cloakable too.
> hmm, why not use a special capability to give
> this kind of access, this would allow you to
> enter a context with or without the ability
> to get the extended /proc/self/status ...
That's what the unused S_CTX_INFO_HIDEINFO in sched.h was intended for?
> > All this might not suit all tastes, so whilst the patch defaults to the
> > most secure option, the usual:
> > echo 1 > /proc/sys/kernel/ctx/visible-self-status
> > echo 1 > /proc/sys/kernel/ctx/visible-sysctrls
> > would restore previous behaviour.
> > Comments please.
> sounds to me like "maybe we could sell a
> virtual server as dedicated machine?"
DSVR's main offering is virtual servers. There's no long term gain in the
sort of deception you're suggesting.
Ease of management means that even our 'dedicated' machines tend to run as
one or more virtual servers.
-- Jonathan Sambrook Software Developer Designer Servers