Re: gs -dNOSAFER / windows

[David Kastrup]

Knut Petersen <address@hidden> writes:

> Am 30.05.2018 um 13:34 schrieb Knut Petersen:
>> Am 30.05.2018 um 11:49 schrieb David Kastrup:
>>>     -dSAFER, that is broken on windows.
>>>
>>>
>>> So the question is: has that apparent group read permission problem (?)
>>> been fixed in the last 13 years?
>>>
>>> Unless somebody has a clue, I lean towards just trying this out and
>>> waiting for problem reports.  At least we should know more or less what
>>> to expect now.
>>>
>> We could add $lilypond-datadir/fonts/otf/ and $lilypond-datadir/ps to the
>> permitted gs resources on the gs command line. Or we explicitly allow all
>> the external fonts used in the document and always use -dSAFER.
>
> As there is a limit of 2048 bytes for command line arguments in ghostscript 
> and
> I managed to hit that limit with experimental code I propose the
> following solution:
>
> 1. Never use -dSAFER and -dNOSAFER on the ghostscript command line.
>
> 2. No special handling of the gs / windows environment.
>
> 3. Always start a postscript file generated by lilypond with code like:
>
>    %!PS-Adobe-3.0
>    %%Creator: LilyPond 2.21.0
>    %%Pages: 1
>    %%PageOrder: Ascend
>    %%Orientation: Portrait
>    %%DocumentMedia: a4 595.28 841.89 80 () ()
>    %%DocumentSuppliedResources: font Emmentaler-20
>    %%DocumentSuppliedResources: font TeXGyreSchola-Regular
>    %%EndComments
>    %%BeginProlog
>
>    << /PermitFileReading [
>    
> (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/ps/music-drawing-routines.ps)
>    (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/ps/lilyponddefs.ps)
>    
> (/home/knut/sources/lilybuilt/share/lilypond/2.21.0/fonts/otf/emmentaler-11.otf)
>    [... a lot of files omitted ...]
>    (/usr/share/fonts/texlive-tex-gyre/texgyreschola-regular.otf)
>    ] >> setuserparams .locksafe
>
> That means we always give a list of all files the document needs
> (fonts, our helper files) to ghostscript
> and then activate ghostscripts safe mode from within the postscript file.
>
> As this could break usage of eps files that try to access external
> files and unsafe postscript code entered
> via \markup \postscript I propose to add a command line option
> '--unsafe-ps' to allow a brave Fred Foobar
> to use the full power of postscript.
>
> Comments? Objections?

Yes to not putting stuff like the file reading permissions on the
command line.

I don't like using .locksafe as opposed to -DSAFER and -DDELAYSAFER (?)
command line options because Ghostscript has a history of fscking around
with any commands not in the PostScript standard.  For example, the
current Ghostscript man page states:

        When  running with  -dNOSAFER it  is possible  to perform  a
        "save" followed  by ".setsafe", execute a  file or procedure
        in SAFER mode,  and then use "restore" to  return to NOSAFER
        mode.   In  order to  prevent  the  save object  from  being
        restored by the foreign file or procedure, the ".runandhide"
        operator should  be used  to hide the  save object  from the
        restricted procedure.

and in spite of this documentation, Ghostscript has just removed the
.runandhide operator without notice, keeping this documentation.

I've been (co-)authoring Ghostscript support for AUCTeX's preview-latex
mode and every year or two preview-latex stops working because
Ghostscript has yet again fscked around with internals previously
documented as doing what they should.

Actually, even the man page (even while apparently not viewed as
authoritive by Ghostscript developers) states:

        While SAFER mode  is not the default, it is  the default for
        many wrapper scripts  such as ps2pdf and may  be the default
        in a  subsequent release of Ghostscript.   Thus when running
        programs  that   need  to  open  files   or  set  restricted
        parameters you should pass the -dNOSAFER command line option
        or its synonym -dDELAYSAFER.

I don't see us getting around .locksafe at the current point of time,
though, so at least in that regard we might need to bite the bullet, but
add -DDELAYSAFER on the command line.

-- 
David Kastrup