Re: Recent ghostscript broke preview-latex again

Hi Ikumi,

On 14/10/2019 17:48, Ikumi Keita wrote:
> Hi Chris,
> 
>>>>>> Chris Liddell <[email protected]> writes:
>> If you are changing the output file name dynamically, from the one on
>> the command line, you could add the output directory to the permitted
>> write directories:
> 
>> systemdict /.addcontrolpath known
>> {
>>   /PermitFileReading (bbb.pdf) .addcontrolpath
>>   /PermitFileReading (bbb.prv/tmp0UabeI/preview.dsc) .addcontrolpath
>>   /PermitFileWriting (bbb.prv/tmp821SQO/) .addcontrolpath
>> } if
> 
>> (Note the trailing '/' on the writable path.
> 
> Thank you very much, this basically sorts out things fine!

So, just so you know what's going on: the trailing '/' means you are
allowing Ghostscript to write to any file name in that directory, but
*only* that directory. If you wanted to allow Ghostscript to write to
any file in that directory, or subdirectory, you could use:

/PermitFileWriting (bbb.prv/tmp821SQO/*) .addcontrolpath


>>> **** WARNING: .lockfileaccess or .setsafe called ****
>>> **** when file access controls are already active ****
> 
>> The warning is benign, although it does indicate that you can calling
>> .setsafe when SAFER is already active.
> 
> This warning is problematic for preview-latex because preview-latex
> regards it as an error and does not pick up the associated image file
> into emacs buffer.  So I changed an element in the initial command
> string given to ghostscript from
> {DELAYSAFER{.setsafe}if}
> to just
> {}
> in order to suppress the warning.  This worked for me.  However, I'm
> just doing try&error method and I cannot tell whether this change leads
> to security hole for earlier version of ghostscript.  Can you tell about
> it?

Well, I suppose we shouldn't get into a warning is a warning, not an
error, and generally should not be treated as an error.....

The warning was added at the request of a user doing similar sorts of
thing to you: he didn't realise that the way his code was working meant
.setsafe was being called multiple times.

Anyway, have it work safely, you'll want something like:

{
  DELAYSAFER
  {
    systemdict /.currentpathcontrolstate known
    {
        .currentpathcontrolstate not
        {
          .setsafe
        } if
    }
    {
      .setsafe
    } ifelse
  } if
}

But, I'm going to make that warning honour the -dQUIET/-q parameter, so
you won't have to worry about that. I'll push the commit tomorrow
morning, and it'll be in the pending release.

>> This can also be done on the command line:
>> --permit-file-write="bbb.prv/tmp821SQO/"
> 
> A brief survey shows that this command line option does not exist in
> Use.html of gs 9.27.  So I suppose we should refrain from using it in
> preview-latex for compatibility with earlier gs.

Yes, and given your workflow, there's no advantage to using the command
line, I only mentioned as information.

>> But there are some things that are confusing.
> 
>> First, on your command line, your output file is in parentheses, but the
>> file name in the error message does not have parentheses.
> 
> I'm not sure what those parentheses are for.  Maybe those are "quotes"
> for PS language and "consumed" by ghostscript?
> 
>> Secondly, the file name on your command line is
>> "bbb.prv/tmp821SQO/pr1-2.png" but the one in the error is
>> "bbb.prv/tmp821SQO/pr1-1.png". So, clearly not the same file.
> 
> Agreed.  In general, preview-latex needs multiple image files for
> multiple math formulae in the latex document.  As far as I understand,
> preview-latex invokes gs only once for those image files and gives input
> to its prompt "GS>" to produce one image file, and waits the next prompt
> to come up, and gives another input to it to produce another image
> file,... and repeats similar cycle until all image files are generated.
> 
> So I think that the error message for "...pr1-1.png" was injected just
> after preview-latex gave input for "..pr1-2.png", and those were
> recorded in the emacs buffer for inter-process communication in that
> order.

OKay, that's not how I think I'd have done it, but it makes sense of
what you're seeing.

So, a big, important thing to realise about the new file access controls
we've implemented: they cannot be deactivated (even with a
save/restore). That *is* a departure from the previous implementation,
but we really had no choice. On the other hand, by allowing you to setup
a writable directory, there is no need to deactivate the controls.

Chris