From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Thu 11 Jul 2002 - 11:44:08 BST
On Wed, 10 Jul 2002 20:45:57 -0500, Herbert Poetzl wrote
> I'm don't know (like with the binding-to-every-IP option) whether it is
> > really practical in the tradeoff for time spent implementing it.
> > Somebody will probably say something if this is /not/ the case.
> I read the documentation, suggesting to
> combine context and 16bit user id to 32bit uid
> to make quota possible ...
> After some DEEP look into the kernel sources,
> I think (please correct me if I am wrong) that
> it should be possible to add a third kind of
> quota (context quota) which limits the space
> available to an entire context ...
> my suggestion is to make the following uid
> mapping in/near the virtual filesystem layer:
> Process [context/16,uid/16] <--> Filesystem [uid/32]
I have tought about this solution as well and came with the following ideas
context/16,0 would represent a special case and would
maintain the sum for all files in a given context.
context/16,uid/16 would do what you propose
The same would be done for group, with no special case.
To make this working, you will need to assign context number by hand to vservers
(which is supported). I was thinking of changing the way security context would
be assigned. Currently 0 is the original (when you boot), 1 is the magic context
used to see everything and then a free context is allocated from 2 and up.
I would change this to 1000. This means that the first 998 security context would
only be usable when explicitly requested. Any vservers not setting S_CONTEXT
would end up using 1000 and up.
> I am willing to try the required modifications
> next week (or the week after) and would be happy
> to get some suggestions/ideas from you ...
Give it a shot and get back ?
If you are an idea to let root in a vserver setup the quota itself for its uid
range, welcome also :-)
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!