Re: LYNX-DEV /tmp patch, round 2

[Jonathan Sergent]

Henry informed us:
 ] The login script for the account in question has this line:
 ]      setenv LYNX_TEMP_SPACE /home/guest/.lynx
 ] The directory .lynx exists in /home/guest (ls -al):
 ]      drwx-----t   2 user          512 Jul 14 11:56 .lynx

what's the point of the sticky bit if only one user can write
to the directory?  paranoia?

here's the deal:  normally you can erase files from a directory
regardless of who owns them if you have write access to the directory.
setting the sticky bit on a directory in most reasonably modern UNIXes
means that if you can write to the directory you can only erase files 
you own from that directory.

I do believe that this (lynx_temp_space) isn't related to this problem.
Does it happen if you _don't_ set lynx_temp_space?

 ] This account has a unique .mailcap entry:
 ]      text/x-archive; /usr/bin/most +s -k %s,
 ] and a unique .mime.types entry:
 ]      text/x-archive                 hog. 
 ] 
 ] If the "user" from within Lynx hits return on a link to
 ] a file with the extension .hog.gz, e.g. myarchive.hog.gz (a
 ] compressed text file) a file by the name ".hog" (literally; not
 ] "myarchive.hog") is created (by Most?) in /home/guest, not under
 ] /home/guest/.lynx (ls -al):
 ]      -rw-------   1 user       369447 Jul 14 19:39 .hog
 ] (This file .hog is indeed the expanded text file that Most
 ] is rendering from within a Lynx session.)

[some speculations.  I know nothing about most, sorry.]

Is lynx decompressing this (do you see gzip -d on the status line?)?
Try doing a -trace and see what filename is getting passed to most,
and what sort of command line it's gunzipping with.  

Where is myarchive.hog.gz located, on the other end of a server, 
file://localhost/path/to/myarchive.hog.gz, what?

 ] I never gave much thought to this and had assumed it was safe
 ] enough, but in order to use Most this way from within Lynx it
 ] seems to be necessary to have the permission on /home/guest
 ] at least as lax as 01755.

I can see why that would be undesirable.  You shouldn't need to actually
decompress it to another file; doing something like
     gzip -dc filename.hog.gz 
should work to send the decompressed stuff to stdout, so you could do
     gzip -dc filename.hog.gz | most
to view this I do believe.  When lynx decompresses things before doing 
stuff with them, it makes the tmp file extension end in .gz or .Z as 
appropriate then does a gzip -d or whatever on the tmp file then it 
opens the file without the .gz or .Z extension.  Unless it's executing
the wrong command to decompress things and then magically finding this
.hog file, I'd have to suspect that neither lynx nor gzip is doing this.

(But maybe I'm off the deep end here. :-)


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