About this list Date view Thread view Subject view Author view Attachment view

From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 25 Oct 2002 - 14:33:44 BST


On Thu, Oct 24, 2002 at 11:07:28PM -0400, tedsuo wrote:
> Hello

> How do you expect to do that *simply*, i mean it look quite
> difficult to play in that.

relevant files should be include/linux/{fs,quota}.h
fs/{dquot,dcache}.c and maybe fs/*/inode.c

> About the virtual filesystem layer where it is, you can send
> us a short text explaining the way you think it should
> be done and we will try in the laboratory.

read below ...

> if everybody get together to work on quota, maybe we will
> get quota up in the next vserver version...

would be nice ...

I guess I should elaborate somewhat on the both
ideas I developed and combined for the context
quota problem.

first idea: "file privileges per context/user"

the requirements:

- files written should get an uid unique to each
  context/user combination.
- no user (not even root) in context A should
  be able to access a file in context B without
  the required unix permission.
- root in the physical server should be able
  to override any permissions (as usual)
  
some math:

- 32bit uid assumed (present in 2.4.x) lets take
  a number N, (32 > N > 0) bits and reserve it for
  context information.
- given a context C (2^N > C > 0), and an user id
  U (2^(32-N) > U > 0), the following function could
  be applied X = (C << N) | (U & (2^N-1)), resulting
  in a new 32bit uid X, which is unique for each
  user/context pair in the defined range.
- the original U/C pair could then be easily
  calculated U = X & (2^N-1), C = X >> N for a
  given X.
  
the idea:

- to simplify calculations and to avoid special
  handling of the "root" case, I would suggest
  to use the following formulae:
  
  X = (U & (2^N-1)) ^ (C << N)
  U = X ^ (C << N)

a simple example (N = 8):

  context A (Ca = 0x11) with three users
  URa = 0x00, U1a = 0x01 and U2a = 0x03 and
  context B (Cb = 0x21) with two users
  URb = 0x00, U1b = 0x01
  
  OP CTX A: CTX B: Physical
  ----------------------------------------------
  W as URa 0x0000 0x3000 0x1100
  W as U1a 0x0001 0x3001 0x1101
  W as U2a 0x0003 0x3003 0x1103
  ----------------------------------------------
  W as URb 0x3000 0x0000 0x2100
  W as U1b 0x3001 0x0001 0x2101
  ----------------------------------------------
  Phys. Root 0x1100 0x2100 0x0000
  
what needs to be done?

- every time an inode is written (modified) the
  mapping function X = (U & (2^N-1)) ^ (C << N)
  has to be applied (if the uid has changed)
- every time an inode is read/verified/etc ...
  the reverse mapping function U = X ^ (C << N)
  must be applied to get the inode ctx-uid

  
second idea: "additional context quota"

- include/linux/quota.h

  #define MAXQUOTAS 3
  #define USRQUOTA 0 /* used for user quotas */
  #define GRPQUOTA 1 /* used for group quotas */
  #define CTXQUOTA 2 /* used for context quotas */

- fs/dquot.c

       case USRQUOTA:
               id = inode->i_uid;
               break;
       case GRPQUOTA:
               id = inode->i_gid;
               break;
       case CTXQUOTA:
               id = (inode->i_uid) >> N;
               break;

what needs to be done?

- minor modifications as given above
- modifications to the quota tools

best,
Herbert

> > On Thu, Oct 24, 2002 at 12:36:27PM -0700, Michael Stowe wrote:
> > > Can any one elaborate on the explantation of implimenting qutoas in a
> > > vserver? The documetation gives only a hint of a concept, but no info
> > > on if it's been done.
> >
> > ------- some time ago, I wrote
> >
> > 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]
> >
> > 32bit uid support is in linux 2.4.x for almost
> > all file systems since 2.4.12 or so.
> >
> > -------
> >
> > unfortunately I did not find the time to make
> > those modifications, although it seems quite
> > simple ...
> >
> > best,
> > Herbert
> >


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:43 GMT by hypermail 2.1.3