From: John P. Eisenmenger (jpe_at_eisenmenger.org)
Date: Fri 25 Oct 2002 - 15:40:43 BST
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 - the context's root user. One
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.
So I guess somehow all utilities that manipulate & verify the /etc/passwd
file would need to understand the context-uid mapping.
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.
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.
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.
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.
-John