From owner-freebsd-current Sat Jun 10 14:31:40 2000 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id BF09A37C814; Sat, 10 Jun 2000 14:31:23 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id OAA58437; Sat, 10 Jun 2000 14:31:23 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 10 Jun 2000 14:31:23 -0700 (PDT) From: Kris Kennaway To: "Andrey A. Chernov" Cc: "Jeroen C. van Gelderen" , Mark Murray , current@FreeBSD.ORG Subject: Re: mktemp() patch In-Reply-To: <20000609234634.A50676@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jun 2000, Andrey A. Chernov wrote: > On Fri, Jun 09, 2000 at 11:23:58PM -0700, Andrey A. Chernov wrote: > > > would be the way to go: 64^6 = 2^36 possibilities which is nice... > > > > 1) Just totally opposite: mixing random with non-random sources you'll get > > into collision much faster then with random source only. 2) Yet, of course, > > the code handles collisions. > > Part 2) need to be clarified too. The code _attempt_ to handle collision, > but collision race can occurse between two processes checking for collision, > so getpid() insertion prevents this. I am not against of removing > getpid() code totally, just against of "randomization" of it, suggested in > the patch, which increase collision chance. The patch doesn't do this -at present it only XORs getpid() with a single random bit which is untouched by getpid() (since PIDs will only be less than 99999). Obviously, overwriting bits which are actually returned from getpid() would be stupid since it turns them totally random and thereby invalidates their use for collision protection. Given the other replies in this thread I think I'll just remove the PID stuff altogether and make the temp filename only constructed from alphanumeric character. The price is that there's a chance of collision between two programs who mktemp() and come up with the same random filename, which is a theoretical security risk (at present only something with the same PID can come up with a colliding tempfile name) but the probability is altogether pretty small. I'll do some calculations to estimate the exact level of risk here. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message