Bug 705699 - “Error: /invalidfileaccess in --file--” when converting PBM file to PDF
Summary: “Error: /invalidfileaccess in --file--” when converting PBM file to PDF
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 9.53.3
Hardware: PC Linux
: P4 normal
Assignee: Default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-07-31 19:33 UTC by alt.d2-9os82yc7
Modified: 2022-08-01 12:49 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description alt.d2-9os82yc7 2022-07-31 19:33:16 UTC
Ghostscript fails to convert PBM files to PDF. Attempts were made with
3 different PBM files:

  1) (scanner) → PDF → (pdfimages -all) → (unpaper) → PBM → (ghostscript/pdfwrite) → error
  2) tex → (LaTeX) → PDF → (ghostscript/pbm) → PBM → (ghostscript/pdfwrite) → error
  3) (imagemagick) → PBM → (ghostscript/pdfwrite) → error

This seems to show that PBMs of any kind produce an error when using
the PDFwrite driver.  Case 2 is interesting because it shows
Ghostscript’s own output is fed back into it and it can’t handle it.
Case 3 is demonstrated below because it requires no source file to
start with (ImageMagick gives a way to generate an arbitrary image
on-the-fly).  So it’s easy to reproduce as long as ImageMagick is
installed.

===8<------------------------------
  $ convert logo: -colors 2 -colorspace gray -normalize pbm:im_logo.pbm
  
  $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo.pdf -- /usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.pbm
  Error: /invalidfileaccess in --file--
  Operand stack:
     (im_logo.pbm)   (r)
  Execution stack:
     %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--
  Dictionary stack:
     --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:87/200(L)--   --dict:0/20(L)--
  Current allocation mode is local
  Last OS error: Permission denied
  Current file position is 10282
  GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
===8<------------------------------

It’s worth noting that case 2 has no problem if the middle step uses
the ppmraw driver instead of the pbm driver. So I thought perhaps a
workaround would be to convert the PBM file produced by unpaper (case
1) to PPM, then feed the PPM file into GS -- but no, the same
“invalidfileaccess” occurs. I also retried case 3 but using a PPM
instead, which also failed:

===8<------------------------------
  $ convert logo: -colors 2 -colorspace gray  -normalize pbm:im_logo.ppm
  $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo_ppm.pdf -- /usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.ppm
Error: /invalidfileaccess in --file--
Operand stack:
   (im_logo.ppm)   (r)
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   1990   1   3   %oparray_pop   1989   1   3   %oparray_pop   1977   1   3   %oparray_pop   1833   1   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--
Dictionary stack:
   --dict:734/1123(ro)(G)--   --dict:0/20(G)--   --dict:87/200(L)--   --dict:0/20(L)--
Current allocation mode is local
Last OS error: Permission denied
Current file position is 10282
GPL Ghostscript 9.53.3: Unrecoverable error, exit code 1
===8<------------------------------

This was originally reported here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016424

but regarded by the Debian maintainer as an upstream bug.

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'testing'), (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ghostscript depends on:
ii  libc6   2.31-13+deb11u3
ii  libgs9  9.53.3~dfsg-7+deb11u2

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.53.3~dfsg-7+deb11u2
Comment 1 Ken Sharp 2022-08-01 07:51:45 UTC
(In reply to alt.d2-9os82yc7 from comment #0)
> Ghostscript fails to convert PBM files to PDF. Attempts were made with
> 3 different PBM files:

Ghostscript doesn't handle PBM as an input format, just PostScript and PDF.


>   $ gs -sDEVICE=pdfwrite -q -r300 -dSCALE=1 -o im_logo.pdf --
> /usr/share/ghostscript/9.53.3/lib/viewpbm.ps im_logo.pbm

Right, so this is more useful. You are using the viewpbm PostScript program to read the PBM file, you aren't reading it with Ghostscript.

The viewpbm.ps program opens the file using the normal PostScript file handling operators:

      /pf fname (r) file def

Recent versions of Ghostscript require you to either use -dNOSAFER or specify any files which the interpreter is permitted to access on the command line.

Note that you cannot specify the files which a PostScript program is allowed to open inside the PostScript program itself, that would obviously be insecure. So viewpbm.ps can't add the files itself, it has to be on the command line.

If you add --permit-file-read=<full path to logo.pbm> to the command line I suspect your file will run correctly. Or add -dNOSAFER, but I would not normally recommend that, it is probably safe enough when running the viewpbm.ps program, assuming you are certain that it is the one supplied by us, and trust us :-)


> It’s worth noting that case 2 has no problem if the middle step uses
> the ppmraw driver instead of the pbm driver. So I thought perhaps a
> workaround would be to convert the PBM file produced by unpaper (case
> 1) to PPM, then feed the PPM file into GS -- but no, the same
> “invalidfileaccess” occurs.

For the same reason, the PostScript program isn't permitted to access random files on the file system.


> This was originally reported here:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016424
> 
> but regarded by the Debian maintainer as an upstream bug.

I don't see it as a bug at all, it's expected behaviour. You need to tell the interpreter that the program is permitted to access the file(s).

When using Ghostscript to open PostScript programs we automatically add the name of the file containing the PostScript program (assuming it is a file) to the list of files which can be accessed (so running viewpbm.ps doesn't require explicit permission). For convenience we also add other files automatically, such as the contents of fontmap and cidfmap files, but not anything else.

The way the viewpbm.ps program works, you need to add any of the files you expect the program to open to the list of permitted files yourself. Or use -dNOSAFER. Presumably convert could be modified to add the PBM filename to the command line with --permit-file-read.

I'll look at changing the Usage string in the viewpbm.ps program though.
Comment 2 Ken Sharp 2022-08-01 12:49:25 UTC
Updated a number of the view*.ps programs here to include the requirement (since version 9.50) to use either -dNOSAFER or --permit-file-read so that the interpreter is permitted to read the input file.

This is now included as part of the 'Usage' if the program has one, or in the comments if that is where the example is.