Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time security policy is incompatible with long-running processes #280

Open
Lastique opened this issue Oct 11, 2023 · 1 comment
Open

time security policy is incompatible with long-running processes #280

Lastique opened this issue Oct 11, 2023 · 1 comment

Comments

@Lastique
Copy link
Contributor

Lastique commented Oct 11, 2023

ImageMagick version

6.9.12-97

Operating system

Linux

Operating system, version and so on

Kubuntu 22.04

Description

We have an application that is running for prolonged periods of time (as a system service). This application is linked with ImageMagick and uses it through its API to process images that are supplied on input.

When policy.xml that is used by ImageMagick contains a time limit (e.g. a line like this: <policy domain="resource" name="time" value="240"/>), our application starts failing because ImageMagick reports errors of the time limit being exceeded. This is because the time limit effectively applies to the pixel cache lifetime (meaning the epoch is initialized on the first use of the cache), and the cache remains active while our application is running. Basically, this means that the time limit is incompatible with long-running applications, even if their use of ImageMagick is occasional and each such use does not take much time.

We feel that such a limitation is not obvious from the limit description in the policy.xml file or the documentation and should probably be better documented. It is also not clear whether this limitation is intentional or not, i.e. is the current behavior wrt. long-running processes intended?

Further, we feel that a different kind of limit would be more useful for long-running processes. More specifically, a time limit for a given operation (e.g. loading an image from a source or saving an image to a file) or a group of operations, which is tracked with user-defined points of start and stop (e.g. by calling APIs to denote the start and stop points). Such a time limit would be tracked on per-thread basis, meaning that there may be multiple threads using ImageMagick APIs concurrently, and each thread should be able to identify their groups of operations individually.

This bug asks to clarify whether the current behavior of the time limit is intended. If it is, we ask you to consider an alternative limit that would be more usable in long-running applications, similar to what is described above.

Steps to Reproduce

  1. Configure a time limit in policy.xml.
  2. Have a long-running application that is linked with ImageMagick and occasionally calls it through its API, e.g. to load an image from a file.
  3. Keep that application running and loading images longer than the configured time limit.

Images

No response

@urban-warrior
Copy link
Member

urban-warrior commented Oct 13, 2023

Thanks for the problem report. We can reproduce the issue and will have a patch to fix it in the GIT main branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://imagemagick.org/archive/beta/ by sometime tomorrow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants