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
> >