Re: LYNX-DEV Improvement on /tmp code fix?

[Jonathan Sergent]

Fote assures me that:
 ]      You're going off the deep end again.  Also, it might have
 ] been a good idea to have looked at it before spending all that time
 ] writing CERT bulletins in reference to it.

Blah, no, I thought about it this time, I was awake this time.  I'm
not off the deep end!  I had diffed it but hadn't built the code or 
played with it or read more of it (as you accuse me of not having done), 
so I only had a suspicion that it was incomplete until yesterday.

 ]      The functions which receive names from tempname() do their
 ] own checks as appropriate, and might come back to tempname() for yet
 ] another name.  Some pass the filename on, while others pass on a
 ] descriptor, and they do the chmod() before closing the file, particularly
 ] in those case where a lag can be expected.

The patch makes sure that if tempname() returns a filename that the
filename in question has been created and it's in a place that's
not spoofable.  The problem is that none of the checks anywhere are 
atomic with creating the file as a normal file, and tempname() is a 
convenient place to put them.  

It's necessary to use O_EXCL when you initially create the temp file to 
avoid spoofing, and it's necessary to not use fopen() to use O_EXCL.  By 
deciding to let Lynx close and open its files repeatedly and not trying 
to fix that, I've decided that people without sticky /tmp's are inherently 
unsafe (because they are!).

My understanding is:

   Lynx never removes a temp file and creates a new one with the same
   name unless tempname() tells it to.  I don't understand the VMS
   removes scattered throughout but I know they don't matter if they're
   preprocessed out of the code on UNIX.

If that holds hold then my patch works on machines with safe temp 
spaces (which the patch also checks for).

The problem with trying to clean up with chmod() after the fact is that 
someone can open the file for write before you chmod it and keep it open 
even after you have done the chmod(), and they can therefore read or muck 
with the contents of your temp file.  It also does absosmurfly nothing
to stop people from removing it if the directory has the wrong permissions.

...

In regards to fchmod() only making the window of vulnerability smaller,
that's right I suppose (opps).  Lynx should old_umask = umask(077) before 
it creates the temp files and then umask(old_umask) after it has done so.  
If users want a umask other than 077 for files that they download (i.e. 
copy from /tmp) to their directories they should be able to use it.

As far as running Lynx on V7 or SVr1, I boggle at whether something like 
that is even possible! 


-- 
Jonathan Sergent / address@hidden / address@hidden
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;