[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28811:; preview-at-point

From: Ken Sharp
Subject: bug#28811:; preview-at-point
Date: Sun, 05 Nov 2017 20:09:34 +0000

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]