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
