bug#28811: 11.90.2.2017-07-25; preview-at-point

[Ken Sharp]

At 19:24 05/11/2017 +0100, you wrote:


> > Make *what* safe ? .runandhide wasn't (directly) an aspect of SAFER or
> > DELAYSAFER, its perfectly possible to have, and write PostScript which
> > is not compatible with SAFER (and which therefore needs to be run
> > before SAFER) but which doesn't require ,runandhide.
>
> The problem is that we need _unsafe_ code to run _after_ SAFER.  From
> the Ghostscript command line that gets back into control after
> .runandhide has interpreted an external file in SAFER mode .

You don't need .runandhide to execute 'unsafe' code, it has other side 
effects. I'm trying to get to the bottom of which of those side-effects you 
need, and why. Part of the problem is that I'm only seeing a tiny fraction 
of the program and have no clue how the bit I have seen is actually used.


> I can run a script teeing off the in- and output instead of running
> Ghostscript directly.  You have to be aware that _any_ such log will
> _not_ demonstrate the need for getting back into unsafe mode since once
> you know all operations you want to do, you can do all unsafe operations
> first and no longer need to revert to unsafe.  The point is that the
> user actions determine the next files to be rendered and thus determine
> the next unsafe operation (namely which file to open next).

But I would very much like to see the sequence of operations, and more 
importantly the whole PostScript program, or at least all the initial 
program. Its terribly hard to make judgements based on a couple of program 
fragments with no context to draw on.


> > I have not said 'we're not putting it back', I've said 'let's discuss
> > this'. If you can please explain why you can't refactor your
> > PostScript to do away with .runandhide then we'll certainly consider
> > this.
>
> Well, I keep explaining it without seeing any point being taken up.

Well I'm sorry, clearly I'm being obtuse. From my perspective you are 
explaining that 'you need to run unsafe code' or 'you need it because you 
need to execute in an arbitrary order'. OK I'm not arguing any of that, but 
I don't see why you specifically need .runandhide in order to do so.

I need a more detailed explanation, why specifically do you need 
.runandhide instead of say exec ?


> That makes it hard to guess where to invest work next with the hope for
> success.

Well, I've asked for a transcript of what gets sent to Ghostscript, that 
would help. Even just the actual initial PostScript program would tell me 
more than what I've seen so far.


> You don't propose any way in which we could change in order to render
> different files outside of the Ghostscript directories in a
> non-prearranged order in safe mode.

That's because I don't see what you are doing now. This is too high level 
an explanation for me to see what it is you are actually doing.


> We've been running around changes in Ghostscript's implementation and
> rules at least 5 times.

Interesting, in what way has Ghostscript changed in the past that's caused 
you problems ? Have you discussed this with anyone ? While I do see your 
name in the archives, it appears to be mostly in discussion with me. Once 
due to strokeadjust and PDF, and once with some other Lilypond stuff. I 
haven't seen anything from AucTeX before. Of course, it could easily 
predate my involvement.

Obviously if there are bugs in the PostScript implementation we have to fix 
them, but that's comparatively rare I would have thought these days.


>   If there was any way guaranteed to actually
> stay around, that would be quite the relief.

Well, first and most obvious would be not to use non-standard PostScript. 
Obviously that's not an option, because the PostScript interpreter allows 
arbitrary execution and traversal of the file system. So you need to use 
-dSAFER if you aren't prepared to trust the PostScript files you are going 
to run.

But you can't simply do that because (it seems to me) you want to run 
Ghostscript 'interactively', except that you don't really mean 
interactively, you really mean in something like a job server loop. 
Interactively to me would mean would mean from the GS command prompt.

Now to me that would suggest that rather than launching Ghostscript and 
leaving it lying around until you want to send it something, you launch it 
once per PostScript program, and close it in between.

You don't want to do that, and I can accept that, but I still do not at 
present understand the way you are using Ghostscript now. Nor do I 
understand the absolute requirement for .runandhide.

I'm trying to understand, but at present I just don't get it.


> > Now I'm prepared to believe that, but I'd like to see why that's
> > required, at the moment I don't see why it is. Maybe we can suggest
> > alternatives that will be satisfactory.
>
> So what do you actully need?

Well, the actual PostScript program would give me context. If you can 
explain why you specifically need .runandhide rather than simply running in 
-dSAFER and using exec that would be good. Also why you need to launch 
Ghostscript and leave it running, rather than launching it once for each 
PostScript program, though that's rather less important (though possibly 
easier to explain).



> > I do need to understand why you need .runandhide; what its doing for
> > you that you need to have,
>
> Being able to run in safer mode, and _yet_ _afterwards_ specify the next
> file to render outside of the Ghostscript accessible tree.
>
> That is all.

Yes but I still don't see why you need .runandhide to achieve this.


> > and can't achieve another way.
>
> Is there another way?

I don't know, because I don't know what it is you are doing now. Yes, I 
know I'm a stuck record here, but I can't suggest an alternative (if such a 
thing is even possible) without understanding how you are currently using 
Ghopstscript. Just knowing what you want to achieve is not sufficient I 
need to know how you are currently achieving it, and ideally, why.


> It puts "unsafe mode" outside of the access of the file running in SAFER
> mode while returning back into it.  That's all.  If you have to store
> the unsafe context anywhere where the file running in SAFER mode could
> access it, there is no actual safety.

And the unsafe context you are storing is what exactly ?


> > Noote that we went through our own code examples removing the
> > requirement from our code, so we are not entirely unfamiliar with
> > techniques to deal with this.
>
> So how did you do that?

Mostly by simply deleting it.

In passing, the reason we removed a lot of these operators was precisely 
because of security concerns. We've recently had a number of reports which 
revolved around non-standard operators being used in unforseen ways. 
Usually these result in crashes but we've also seen denial of service, 
directory and file traversal/retrieval and some cases where it was possible 
to execute arbitrary code. Note that these have been true in some instances 
even when -dSAFER is set.

Obviously those reported problems have been fixed, but it seemed reasonable 
to reduce the attack surface by removing operators which are no longer 
required, or not required after startup.

Now we fully expected to have to work with Ghostscript users afterwards, 
we've had some customers and some free users discuss the changes with us. 
So far we've been able to help them remove the requirements from their own 
code but that doesn't mean we *won't* restore the operators if they are 
genuinely needed. It does mean that we would like to talk about it and 
understand the requirements properly first.


Given the rather acrimonious past history of our discussions, I think it 
may be better if I hand this to a colleague. I'll speak to someone tomorrow 
and see if they are willing to take it on.



                        Ken