From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 25 Oct 2002 - 16:18:16 BST
On Fri, Oct 25, 2002 at 09:40:43AM -0500, John P. Eisenmenger wrote:
> On Friday 25 October 2002 08:33 am, Herbert Poetzl wrote:
> > 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.
>
> As long as X <= 2^N-1, which is your underlying assumption.
> Once X hits 2^N you'll get an effective context-uid of 0
you probably mean U and not X because X is computed
from C and U and has only the 32bit limit, but you
are right, any U which is a multiple of 2^N would
become equal to root.
but fortunately I already have a solution for that case
(I only forgot to mention it):
- multiples of 2^N for U should be mapped to (2^N-1)
which, in any normal system should hit no real account.
(N=16, 2^N-1 = 65535 which actually is nobody)
> would think a 24-bit UID + 8 bits for context id would be
> more than generous, but evil things could happen without
> the tell-tale uid=0 in the passwd file.
I thought more of 16/16 splits ...
> So I guess somehow all utilities that manipulate & verify
> the /etc/passwd file would need to understand the
> context-uid mapping.
I don't think so ...
if the kernel limits UIDs to N bits (N < 32) there
should be no problem with the utilities supporting
up to 32bits (actually only 16bits are used)
> Also I believe the default context number is dynamic unless
> specified in the vserver.conf file via the S_CONTEXT option.
> Thus setting a static context number would become a
> requirement lest a context lose access to its own files
> whenever it is started.
Yep, thats right, I forgot it too, because I use
static context numbers for the last half year ...
> Generating the vserver directory tree would also become
> a bit more complicated due to a need to map all file
> ownerships to the appropriate context-uids.
that depends, because the unified contents would/should
remain owned by the physical root, which *smile* brings
up the next issue I completely forgot:
- physical root (X = 0) or physical UIDs (X >> N) == 0
could/should be mapped by U = X (i.e. not changed)
> This shouldn't be a biggie since the physical root
> generating the vserver area can chown files to anything.
> It just needs to be considered at
> vserver-creation time.
of course if desired, the whole virtual server could
be "transposed" into the context UID space.
> Man, I sound like a downer... It is a good idea and I
> believe it is workable, but I think these issues need to
> be addressed to prevent problems down the road.
on the contrary, last time as I mentioned the
quota topic, nobody seemed to be interested, and
no one actually discussed it ...
best,
Herbert