Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <3E678A49.707BF9D0@ieee.org> Date: Thu, 06 Mar 2003 12:50:01 -0500 From: "Pierre A. Humblet" X-Accept-Language: en,pdf MIME-Version: 1.0 To: cygwin-developers AT cygwin DOT com Subject: Re: uid > 64k References: <3E675F8D DOT 414B9BBD AT ieee DOT org> <20030306164822 DOT GT1193 AT cygbert DOT vinschen DOT de> <3E6780A9 DOT F1F32899 AT ieee DOT org> <20030306171033 DOT GB7674 AT redhat DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > Couldn't you just keep track of the uids and ensure that you didn't > duplicate any? Yes, absolutely. However there is no guarantee that users won't call separately mkpasswd -l and mkpasswd -d, or another mkpasswd -d other_domain, or mkpasswd -d -u It would be desirable to return the same uid in all these cases. Thus for a start I would not go that route, but use a simple deterministic hash (as Max suggested). Anyway it's just a temporary fix until we turn on uid32 BTW, the probability of no conflict if we randomly map 100 uids between 10001 and 60000 is 1 * (1- 1/50000) * (1 - 2/50000) * ... * (1- 99/50000) = exp( 0 + ln(1 - 1/50000) + .... + ln( 1 - 99/50000)) ~ exp (0 - 1/50000 - 2/50000 - ... - 99/50000) = exp ( - 99 * 100 / 2 / 50000) = exp ( - 0.099 ) ~ 1 - .01 So in that already big case there is a 1% chance that there will be some conflict. The probability that a specific uid does not conflict with any of the others is (1 - 1/50000) ^ 99 ~ (1 - 99/50000) ~ 1 - .002 So the probability that there will be aliasing with the current user is about .2% (and even then there a 50% probability that the aliasing won't hurt) Pierre