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

[Jonathan Sergent]

Tom commented:
 ] not all systems support 3-parameter 'open()' - probably not a lot anymore,
 ] but they exist - and some of them are prototyped (I remember being bitten
 ] by that).  we'll have to work around this at some point - though I agree
 ] in principle with what you're suggesting, the details aren't right yet.

I remembered you having said that in another message.  It seems to me that
a #define for such systems (or a -D on the command line) and an fchmod()
would solve the problem.

Are these systems like the mythical ones that lynx compiles on that
don't support symbolic links, or the mythical ones that lynx compiles
on that don't support sticky directories?  Just curious.  Examples,
revised Makefile targets, and a few #ifdef sets are all that's needed.

I'm trying to figure out how fdopen() could possibly help, though; I
don't need it for fchmod.

I don't need a stream for the thing in tempname(), and I don't care
about the exclusive stuff in the rest of the program if I know the
file is mode 0600 and others can't remove it.

...

I just realized that to make the "safe place checks" appropriate, I also
need to stat the parents of lynx_temp_space up to the root (well, the
other direction would be safer) and perform the same checks on them 
(and confirm that they're all owned by a uid <100 [i.e. system directories 
of some sort] or the user)...  

If I could access the stuff at the URL I posted in my last message 
comfortably I could probably manage to get this here modem to behave 
so I could log in without having to boot into MS-DOS (ack!), and I'd 
send another patch.

Here's something for some sort of documentation on the error message
that my patch generates for unsafe temp spaces:

------------------------------------------------------------------------
*** ALERT *** Your temp space may be unsafe! Contact your administrator.

Users who get this message should contact their system administrators
to fix the problem, described below.

System administrators:

If you get this message, it means that the location in which Lynx was
instructed to store temporary files is not safe (i.e. it may be 
possible for other users to overwrite things that users download or
even other files they own on the system).  To get rid of this message,
you need to change the temp space to a safe place.  Usually, the
/tmp directory is a safe place to put temporary files; however, if 
the /tmp directory isn't a "sticky directory", it is possible for
one user to erase files (in /tmp!) owned by other users.  If your
system supports "sticky directories" then set the sticky bit on
/tmp ("chmod +t /tmp").

If for some reason making /tmp sticky is not an option, you are
advised to use individual temporary directories per user.  To do
this, you'll need to instruct Lynx to store temporary files in
a directory such as "~/.lynx" or "/tmp/$USER".  You can instruct
Lynx to use a different directory by either (a) setting the
LYNX_TEMP_SPACE environment variable to the name of the directory
to use, or (b) editing the "userdefs.h" file in the Lynx source
distribution and editing the "#define TEMP_SPACE" line, then 
recompiling Lynx.

You can edit the tempname() function in LYUtils.c if you want to
bypass this security precaution, however it is dangerous and you
ought not do so unless you understand the implications of it.
------------------------------------------------------------------------


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