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

[T.E.Dickey]

> 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.
I'd end up doing it in the configure script in any case.  I think that
the mode parameter can be made redundant as well by using umask.
 
> 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.
sticky directories are fairly recent - I don't remember noticing them before
Sun's NFS stuff took hold in the early 90's. symbolic links have been around
a bit longer than that (they weren't in SVr1, I think).
 
> I'm trying to figure out how fdopen() could possibly help, though; I
> don't need it for fchmod.
if you open the file with the right permissions, you don't need to chmod it.
you should be able to wrapper this to construct the filename and return the
pointer to it as one operation, that way you aren't going to be concerned
about someone else using the file.
 
> 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)...  
that's expensive, and you have to know how to transit mount points (that's
not very portable either - it'd be a pain to implement)

-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;