UNIX / Linux keyboard.

Solution to ImageMagick "not authorized" PDF Error

ImageMagick "not authorized" PDF errors

Here's the scenario: I have scanned a multi-page document using Xsane. I named the first one scan-0001.jpg and Xsane automatically incremented the number for each new file. Now I want to convert that collection of JPEG images into one PDF file. This used to work, but now I just get an error:

$ ls
scan-0001.jpg   scan-0002.jpg   scan-0003.jpg   scan-0004.jpg
$ convert scan*.jpg scan.pdf
convert-im6.q16: not authorized `scan.pdf' @ error/constitute.c/WriteImage/1037.

What has happened?

ImageMagick has supported a security policy for some time. The ImageMagick project itself, and the Linux distributions in which it's included, have made the policy a little more strict. Now it refuses to write PDF and Postscript files on my system. The error message is true, but it isn't helpful. I don't care precisely where within the code that it was denied, I just want to know how to turn this on! Read on...

There's an ImageMagick Security Policy?

Package management commands

ImageMagick uses a file named policy.xml to control its security policy. On the Linux Mint system where I'm writing this, there are three packages: imagemagick, imagemagick-6-common, and imagemagick-6.q16. The configuration files are under /etc/ImageMagick-6/.

$ dpkg -l | awk '/imagemagick/ {print $2}'
imagemagick
imagemagick-6-common
imagemagick-6.q16
$ dpkg --listfiles $(dpkg -l | awk '/imagemagick/ {print $2}') | grep policy
/etc/ImageMagick-6/policy.xml
$ ls /etc/ImageMagick-6/
coder.xml      magic.xml               thresholds.xml        type-windows.xml
colors.xml     mime.xml                type-apple.xml        type.xml
delegates.xml  policy.xml              type-dejavu.xml
log.xml        quantization-table.xml  type-ghostscript.xml 

The ImageMagick site's page describing the security policy contains some good insights.

Security is a trade-off between a secure environment and convenience.
[...]
The security policy covers areas such as memory, which paths to read or write, how many images are permitted in an image sequence, how long a workflow can run, how much disk the image pixels can consume, a secret passphrase for remote connections, which coders are permitted or denied, and others. These policies should provide robust coverage to not only secure your environment per your requirements but also ensure ImageMagick remains a good citizen (e.g. prevent thrashing with large images) in your local environment.
[...]
Only you can decide what are reasonable limits taking in consideration your environment. We provide this policy with reasonable limits and encourage you to modify it to suit your local environment.

I use ImageMagick on my computer. Sometimes my laptop with 3 GB of RAM and a single-core CPU, and sometimes my main desktop with 8 GB of RAM and a 4-core CPU. I'm the only user on either one.

However, ImageMagick is frequently used on Internet-facing servers. It might run in a limited sandbox-type environment like LXC or Linux Containers, operating through Docker or Kubernetes. But, these systems frequently process potentially hostile data submitted by users. When you perform some ImageMagick tasks on unusual input, the process may unexpectedly explode in memory or file system size, or in CPU utilization.

I don't care — if I saturate the CPU or memory, I did it so I won't blame the program. However, we have to understand that ImageMagick tries to be reasonably safe when installed in a default configuration. If I want to live more dangerously, I can. I just have to reconfigure its policy.

ImageMagick
Security Policy

ImageMagick's default security policy imposes limits of 256 MiB memory, image dimensions of no more than 8196 pixels high or wide, files can be no larger than 1 GiB, individual tasks can take no more than 120 seconds, and others. See the ImageMagick security policy page for more details.

That's just how the ImageMagick project sets things up.

Then, someone assembling a Linux distribution, or building a smartphone app, can change those limits up or down.

There's an easy way to see the current security policy settings on your system:

$ identify -list policy | less 

Some Image Data Can Be Dangerous

Realize that PostScript is actually a programming language which is interpreted by something — a software tool such as gv or ghostview, or a hardware device such as a printer. And, PDF or Portable Document Format is based on Postscript.

So, the default build of ImageMagick prevents reading or writing PostScript, PDF, and other related formats handled by ghostscript. Some distributions have changed the policy to re-enable that, but many do not.

How to Turn On Postscript, PDF, and Others

Examine your policy.xml file. Check whether or not it contains directives to disable certain data types. Here's the default Linux Mint policy.xml file. Remember that you will have to find where that file is stored, but I show you how to do that above. Here I have highlighted the two that will cause me trouble, I don't need or want EPI or XPS:

$ more /etc/ImageMagick-6/policy.xml
[... about 70 lines deleted ...]
  <!-- disable ghostscript format types -->
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="EPI" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
</policymap> 

Edit the file as root and make these changes. I'm commenting out the four lines denying access, and adding one new line that gives read and write access to the two types I want:

[... about 70 lines deleted ...]
  <!-- disable ghostscript format types -->
  <!--
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="EPI" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
  -->
  <policy domain="coder" rights="read|write" pattern="PDF|PS" />
</policymap> 

Problem Solved!

$ convert scan-*jpg scan.pdf
$ convert scan-*jpg scan.ps
$ ls -l scan*
-rw-r--r-- 1 cromwell cromwell   131879 Nov 22 10:34 scan-0001.jpg
-rw-r--r-- 1 cromwell cromwell   137088 Nov 22 10:35 scan-0002.jpg
-rw-r--r-- 1 cromwell cromwell   132204 Nov 22 10:35 scan-0003.jpg
-rw-r--r-- 1 cromwell cromwell   133016 Nov 22 10:36 scan-0004.jpg
-rw-rw-r-- 1 cromwell cromwell   479604 Nov 22 11:41 scan.pdf
-rw-rw-r-- 1 cromwell cromwell 13517838 Nov 22 11:41 scan.ps 

It's Solved, But...

This policy makes sense! It should be there. I hadn't happened to consider this specific application, but I quickly realized that it would be used for many Internet-facing solutions. Let users upload an image, and then get it into reasonable size and shape. But it might be a memory bomb or a hostile Postscript or PDF file.

However...

This is yet another case of an open-source OS environment saying "Guess what, here's yet another language you must know in order to run a server." Linux is the most obvious example by far, but ImageMagick runs just fine on FreeBSD and is still configured in XML.

There isn't much to XML, at least not as used here. XML is fussy, you have to be strict about matching, unlike HTML where you can be sloppy. If you know to be very careful, you can program by analogy and hints from what's already there. And you should always be very careful any time you're doing anything as root, such as editing a configuration file!

Getting started with PolicyKit

It could be worse. The PolicyKit packages are configured with Java!

Back to the Linux / Open-Source Page