Re: lynx-dev security patch for LYUtils.c

[T.E.Dickey]

> 
> This partially fixes the temp file races I was talking about.  It fixes 
thanks (will see - I put together a more elaborate one this morning, which
I'll test tonight - it works around the problem with symbolic links which
you pointed out, avoiding the race that remains here before the unlink, as
well as being a little more conservative about the check on the public
directory).

> the ones introduced in dev.19, while attempting to solve the same 
> problem that change was trying to solve: users tripping over their own 
> leftover temp files.  This makes one attempt to delete the old temp file 
> (which will only succeed if it's owned by the user, or the user owns the 
> directory, or it's in a *non*-sticky public directory).  If it can't be 
> deleted, we fall back on error handling code (which I believe will move 
> on to the next possible temp file name). 
>  
> There are still serious security problems with the open-for-append code, 
> which is used in a number of places.  These problems have existed for a 
> long time.  Particular areas of danger include: 
I've had those on my list as well (the filename-caching as well).
  
>   - doing a traversal while your current directory is writable by anyone 
>     other than yourself 
>  
>   - posting any mail or news message with Lynx when ~/.lynxsig exists 
>  
> There may still be problems with the open-for-write code as well.  I ran 
> out of time to check it tonight. 
>  


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey