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

[Jonathan Sergent]

Bela informed us:
 ] For the System V lineage, everything being discussed is "new".  Sticky
 ] directories are new as of SVR4.  fchmod() is new as of SVR4.  Symbolic
 ] links are new as of SVR4.  Many other non-BSD, non-SysV OSes exist which
 ] will likewise have some arbitrary mix of features.

This sounds like a job for autoconfigure to straighten out, not something
that should be automagic.

 ] The *ONLY* safe method I know of is to invent a filename, open it with
 ] O_CREAT | O_EXCL, and use it without ever closing it.  This requires
 ] neither sticky directories (and a walk-from-the-root to confirm them)
 ] nor fchmod(), and it's proof against symlinks.

My plan was to not attempt to do anything special like this on systems 
without sticky directory support, allowing them to create per-user
temp directories or disable the checking.

We needn't concern ourselves with systems lacking symlinks, I don't
think, as they clear themselves of problems with the spoofing attack.

Problems with systems lacking lstat() or 3-arg open() ought be solved
with preprocessor macros like:

#ifdef NO_THREEARG_OPEN
#define open(x,y,z) open(x,y)
#endif
#ifdef NO_LSTAT
#define lstat(x,y) stat(x,y)
#endif

(or more suitable named and orientations) I would think.

I do believe we gave up on fchmod().

 ] You can't assume uid < 100 == "system".  (The least supportable part of
 ] that assumption is that uid >= 100 != system.)

Fine.  I think the PD trustfile() code is the way to go on this.
It supports a list of trusted users to own things; it seems quite
suitable.

 ] Regarding mythical systems: I have successfully compiled Lynx (a 2.5FM
 ] code set, a while back) for SCO Xenix, which does not support any of
 ] symlinks, sticky directories, or fchmod().  ["I successfully compiled"
 ] != "compiles on": it was a one-off with a considerable amount of
 ] kludging in the source, which was not fit to be handed back to the dev
 ] team.]

I don't disagree that this isn't possible, but I do wonder if it's 
necessary to burden ourselves with not breaking older releases of 
operating systems in new versions of web browsers unless we have
a patch or a request from a bona fide user of Lynx on such an
operating system to do this or that so that the code compiles there.

Does anyone have any hints as to preprocessor macros that will be
defined to indicate whether open() takes three arguments?


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