Re: InitializeMagick() causes GraphicsMagick to not find its config files

On Wed, 24 Feb 2010, Graham Leggett wrote:
>
> The underlying error was "permission denied", which I'll go into further 
> below, the problem was that this error wasn't communicated back to the caller 
> (I suspect all errors are being interpreted as meaning "file not found"?). 
> Instead, GraphicsMagick was allowed to continue, which then did this:

There is a good reason why GraphicsMagick continued.  The reason is 
that after not finding a coder to support the format, it tries to find 
a delegate (external program) to indirectly support the format (JPEG 
could easily be supported via 'djpeg').  Then the "delegate" error is 
the one finally displayed since it is the last error.  I have agonized 
over this quite a lot in times past but could not figure out how to 
offer a better error message since it is not possible to know which 
one best applies.  If errors were organized more like a list, then a 
full list of all issues (including many bogus ones) could be reported.

> Stumbling on without a jpeg driver, GraphicsMagick now threw the error that 
> jpegs weren't supported.  Ideally, GraphcisMagick should have failed earlier, 
> as permission denied for its configuration should either be fatal, or should 
> be added to the "I don't support jpeg" message (like maybe "I don't support 
> jpeg, when I tried I got permission denied").

One would think that this should be the case except that 
GraphicsMagick is designed to allow looking in multiple places and 
errors like "access denied" or "file not found" can be normal 
occurances.

> The reason for the "permission denied" was that this machine for some reason 
> historically had had a umask manually set of 0077.
>
> When the RPM was installed, the directories containing the config files seem 
> to have been created in a postinstall script, instead of being declared 
> explicitly in the spec file to have the specified ownership and permissions.

Did you build and install from the SRPM file that the GraphicsMagick 
project distributes, or from some other RPM file?  I have little doubt 
that the SRPM package currently has some issues since I currently 
don't have an RPM-based Linux install to test with.  I do plan to 
install CentOS or Fedora here in order to improve the SRPM package.

> As a result, the umask kicked in making the directories and the config files 
> below them only accessible when run as root. Ideally, the spec file should 
> declare explicit permissions for the directories below the following path:
>
> /usr/lib64/GraphicsMagick-1.3.10/modules-Q8/*

Patches for the SRPM spec file (GraphicsMagick.spec.in is the 
master) are always appreciated.

Thank you very much for following up and reporting the issue.  It 
would help if you could file a formal report via the SourceForge bug 
tracker so that the issue won't be forgotten.

Bob
--
Bob Friesenhahn
[email protected], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev