[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37719: [gs-devel] Recent ghostscript broke preview-latex again
From: |
Chris Liddell |
Subject: |
bug#37719: [gs-devel] Recent ghostscript broke preview-latex again |
Date: |
Mon, 14 Oct 2019 18:49:57 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
Hi Ikumi,
On 14/10/2019 17:48, Ikumi Keita wrote:
> Hi Chris,
>
>>>>>> Chris Liddell <address@hidden> 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
- bug#37719: 11.91; preview-latex not working (again?), (continued)
- bug#37719: 11.91; preview-latex not working (again?), Ikumi Keita, 2019/10/13
- bug#37719: 11.91; preview-latex not working (again?), Dylan Thurston, 2019/10/13
- bug#37719: 11.91; preview-latex not working (again?), Ikumi Keita, 2019/10/15
- bug#37719: 11.91; preview-latex not working (again?), Dylan Thurston, 2019/10/16
- bug#37719: 11.91; preview-latex not working (again?), Ikumi Keita, 2019/10/16
bug#37719: Recent ghostscript broke preview-latex again, Ikumi Keita, 2019/10/13
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again, Chris Liddell, 2019/10/14
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again, Ikumi Keita, 2019/10/14
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again, Chris Liddell, 2019/10/14
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again, Ikumi Keita, 2019/10/14
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again,
Chris Liddell <=
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again, Ikumi Keita, 2019/10/15
- bug#37719: [gs-devel] Recent ghostscript broke preview-latex again, Chris Liddell, 2019/10/15