Bug 691780 - -dSAFER seems to prevent loading of a ttf font
Summary: -dSAFER seems to prevent loading of a ttf font
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: General (show other bugs)
Version: 9.00
Hardware: PC Linux
: P4 normal
Assignee: Ray Johnston
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-17 18:23 UTC by Bob T.
Modified: 2020-12-27 19:32 UTC (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
truetype font file (40.15 KB, application/octet-stream)
2010-11-18 12:45 UTC, Bob T.
Details
Postscript test file. (11.20 KB, application/postscript)
2010-11-18 12:46 UTC, Bob T.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bob T. 2010-11-17 18:23:26 UTC
ps2pdf failed to load luximr.ttf. But when I used 

gs -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=test.pdf -c .setpdfwrite -f test.ps

the conversion worked.  The only difference is that -dSAFER has been deleted, and adding it again results in failure.

The luximr.ttf file is in a directory that is on the search path (as reported by gs -h) and there's a Fontmap in that directory.

On another machine that has gs-8.62 and the same font configuration, the ps2pdf conversion works.

Here are the relevant outputs of the failures:

Querying operating system for font files...
Loading NimbusMonL-Bold font from /usr/share/fonts/default/Type1/n022004l.pfb... 3432244 2089215 5841672 4006058 1 done.
Can't find (or can't open) font file /usr/share/ghostscript/8.71/Resource/Font/LuxiMono.
Can't find (or can't open) font file LuxiMono.
Didn't find this font on the system!
Substituting font Courier for LuxiMono.


And for successes (without -dSAFER):

Querying operating system for font files...
**** Warning: glyf overlaps cmap, truncating.
**** Warning: glyf overlaps cmap, truncating.
**** Warning: glyf overlaps cmap, truncating.
**** Warning: glyf overlaps cmap, truncating.
**** Warning: glyf overlaps cmap, truncating.
Loading NimbusMonL-Bold font from /usr/share/fonts/default/Type1/n022004l.pfb... 3532724 2176095 6992696 5541964 1 done.
Loading LuxiMono font from /usr/local/share/fonts/luxi/luximr.ttf... 3532724 2177970 7164336 5689719 1 done.
Comment 1 Ken Sharp 2010-11-18 08:39:11 UTC
You haven't supplied either the font or the PostScript file causing the problem, we can't comment or fix any problem without being able to reproduce it. We'll also need the relevant fontmap entry of course.

You've said that the problem is using -dSAFER and quoted a command line, but you say you are using ps2pdf, which is it? Please try just the command line with and without -dSAFER in order to eliminate any scripting or shell issues (and potentially allow reproduction on other systems). If that's what you did, then just let us know to clear up my confusion.

Although you've marked this as a PDF Writer problem, it seems unlikely that it really is. If the issue is -dSAFER then this is nothing to do with PDF production. You could test that by not specifying a device, in which case GS will display the file on screen, or specifying some other device (eg tiff24nc to produce a TIFF file). 

Finally, the action of -dSAFER has been altered in gs 9.0, you may want to check what that does.
Comment 2 Bob T. 2010-11-18 12:45:45 UTC
Created attachment 6923 [details]
truetype font file
Comment 3 Bob T. 2010-11-18 12:46:48 UTC
Created attachment 6924 [details]
Postscript test file.
Comment 4 Bob T. 2010-11-18 13:05:34 UTC
The Fontmap is just 

/LuxiMono (./luximr.ttf)

gs -dSAFER test.ps fails and gs test.ps succeeds.  I don't have gs-9.0 on any machine but gs-8.62 doesn't have this problem. My Linux distribution (Fedora 13) provides
a package for 8.71 but heavily patched so it's possible that unpatched 8.71 is okay.
If you can't duplicate the behaviour I'll report the bug to the Fedora bugzilla.

Here is the search path reported by gs -h:

    /usr/local/share/fonts/msweb :  /usr/local/share/fonts/TrueType  :
    /usr/local/share/fonts/Type1  :  /usr/local/share/fonts/luxi  :
    /usr/share/fonts/default/Type1  :  /usr/local/share/fonts/AdobeType1 :
   /usr/share/ghostscript/8.71/Resource/Init :
   /usr/share/ghostscript/8.71/lib :
   /usr/share/ghostscript/8.71/Resource/Font :
   /usr/share/ghostscript/fonts : /usr/share/fonts/default/ghostscript :
   /usr/share/fonts/default/Type1 : /usr/share/fonts/default/amspsfnt/pfb :
   /usr/share/fonts/default/cmpsfont/pfb : /usr/share/fonts :
   /usr/share/ghostscript/conf.d : /etc/ghostscript : /etc/ghostscript/8.71

The font file is
 
/usr/local/share/fonts/luxi/luximr.ttf
Comment 5 Ken Sharp 2010-11-18 13:14:25 UTC
(In reply to comment #4)
> The Fontmap is just 
> 
> /LuxiMono (./luximr.ttf)

Needs a trailing semicolon ;-)

 
> gs -dSAFER test.ps fails and gs test.ps succeeds.

OK, that's good, its not the scripting.

>  I don't have gs-9.0 on any
> machine but gs-8.62 doesn't have this problem. 

8.62 is archaic, and obviously things do change. We've had a number of complaints about the action of -dSAFER and -P- from security people, and so these have been changed a couple of times.

> My Linux distribution (Fedora
> 13) provides
> a package for 8.71 but heavily patched so it's possible that unpatched 8.71 is
> okay.
> If you can't duplicate the behaviour I'll report the bug to the Fedora
> bugzilla.

I don't have a copy of 8.71 to hand on Linux, but 9.00 on both Windows and Linux reports an 'invalidfileaccess' error. This occurs (unsurprisingly) no matter what the device, so this is not a PDF Writer problem.

This (search paths and security) isn't my area, so I'm not sure if this is intended by design or not. I've altered the component to 'General' and reset the assignment to support so that this gets re-assigned to whoever owns this area of the code.
Comment 6 Ray Johnston 2010-11-18 18:57:15 UTC
Please fix your Fontmap file to be:
   /LuxiMono (luximr.ttf) ;

Note the space before the ';'

The directory '.' is NOT on your search path as it was with 8.71 (refer to
the -P- default behavior in 9.00)

Also you can try -P or -I. to place '.' on the search paths.
Comment 7 Bob T. 2010-11-18 21:20:20 UTC
(In reply to comment #6)
> Please fix your Fontmap file to be:
>    /LuxiMono (luximr.ttf) ;
> 
> Note the space before the ';'

Done.  No difference.

> The directory '.' is NOT on your search path as it was with 8.71 (refer to
> the -P- default behavior in 9.00)
> 
> Also you can try -P or -I. to place '.' on the search paths.

The font and Fontmap are not in ., but they're in a directory that *is* on the search path (/usr/local/share/fonts/luxi).

BTW the font I attached is actually the Type1 version of LuxiMono Regular.  But replacing it by the ttf version doesn't change the behaviour.
Comment 8 Bob T. 2010-11-22 03:44:07 UTC
I've built gs-9.00 from the source tarball and it exhibits the same behaviour as reported before:  

gs test.ps works:

  Loading LuxiMono font from /usr/local/share/fonts/luxi/luximr.ttf... 
  
gs -dSAFER test.ps does not:

  Didn't find this font on the system!
  Substituting font Courier for LuxiMono.

I've changed the Version for the bug to 9.00 on the assumption that bugs in the most recent version will get more attention.
Comment 9 Peter Cherepanov 2020-12-27 19:32:31 UTC
Current Ghostscript can query the system and load fonts in the safe mode just fine.