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
