http://bugzilla.novell.com/show_bug.cgi?id=608071 http://bugzilla.novell.com/show_bug.cgi?id=608071#c32 --- Comment #32 from Christopher Yeleighton <giecrilj@stegny.2a.pl> 2010-06-03 14:38:32 UTC --- (In reply to comment #17)
(In reply to comment #14)
Aha! So the root of the problem is that -dSAFER isn't honored for those initialization files.
The root of the problem is that Ghostscript insists on reading encodings up front, and assumes that whatever is in an Encoding directory is an encoding program.
If we accept this, although I really do not think we should, the root of the problem is that Ghostscript allows relative path search in its initialization phase.
Correct me if I am wrong but the information supplied upstream [1] seems to indicate that Ghostscript, just like Emacs, does not run its start-up code when it starts with a core ROM image that is prebuilt unless this feature is switched off. This feature can be turned off during build; it is on by default but it is turned off in openSuSE [2]. It seems that Ghostscript should not be vulnerable when it starts off a core image. OTOH, it makes sense for the code in (gs_fntem.ps) to load all possible encodings ONLY IF it is building the start-up image because a safe environment can be assumed at build time. Summary: I hereby suggest that generating and using the core image for Ghostscript should be turned back on. == References == [1] <URL:http://bugs.ghostscript.com/show_bug.cgi?id=691316#c7> [2] <URL:http://bugs.ghostscript.com/show_bug.cgi?id=691316#c9> -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.