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.


In God we Trust -- all others must submit an X.509 certificate.
    -- Charles Forsythe <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to