Re: LYNX-DEV LYNX, change temp download dir from /tmp

[Jonathan Sergent]

TD:
 ] I thought my umask/chmod combination is reasonably ok (but someone pointed
 ] out that if the Lynx user is 'root', then the tests aren't appropriate).
 ] Anyway, fixing _that_ should be a matter of making a more sophisticated
 ] chunk of code to replace the contents of OpenHiddenFile - right?

Yeah, pretty much.  The root thing isn't an issue.  The issue is
the race between the tempname and the chmod and any other process
on the system.  chmod does not fail on symlinks that point to files 
which exist.  So you must slip in a symlink to something you want
overwritten between the tempname call and the OpenHiddenFile.  This
may be easier than it sounds.

mkstemp doesn't do much for Lynx since it needs to reuse temp files.
Way back, Klaus wrote a patch that let Lynx keep temp files open
until they were no longer needed.  This seems overly complicated
to me, since it requires lots of (duplicated) code to change.  What
mkstemp does is atomically test and create the file, and leave it
open for you.  If you don't plan to re-open the file, this is safe
even on systems without sticky directory support.  But Lynx plans
to re-open the file.

It makes sense to replace tempname() with a call to create a temp file 
name with a given extension.  The tempname() call can create the file 
with the correct permissions at the same time as checking whether 
it's an okay thing to create by using open with O_EXCL | O_CREAT.  
Doing the "does file exist" and "please create file with this mode"
in one system call is the key.

If /tmp is not 'sticky' then other users can mess with the file after
the fact which totally ruins everything if you will be saving something
in the file and re-opening it.  There's not any way around that other
than keeping the file open, which is not something worth the trouble 
since the number of multi-user systems like that which are connected to 
the Internet and have Lynx installed is probably not very large.  Plus
it requires changing large quantities of Lynx code.

 ] sounds right - but I don't know how to verify that at configuration time
 ] (i.e., that the sticky-bit actually does something useful).

I don't think you need to try to.  What would you do if the test failed?  
stat is as good as you can try to do.

cat <<EOF
 /tmp on this machine does not have the sticky bit set.  Most systems 
 today support "sticky directories".  If your system supports these 
 (in all likelihood it does), it is recommended that you run the 
 command "chmod +t /tmp" (or ask your system administrator to do so).
 Not doing so may have adverse security implications.  Alternatively, 
 set TEMP_SPACE to point somewhere safer than /tmp.  Please contact 
 the LYNX-DEV mailing list if you have questions about this.  
EOF

At end of configure script so that it is still readable by user, then go 
ahead and create makefile and lynx_cfg.h as normal.  If we hear of any 
platforms that Lynx compiles on that don't support that bit on 
directories, we can add special cases for them...


-- 
Jonathan Sergent / address@hidden