Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a problem with file permissions which is driving me crazy. I have a Perl web app which installs itself, copying some files, creating DB, and so on. All works fine, except for some image files. These images aren't accesible by Apache:

(13) Permission denied: access to /path/to/image.gif denied

But, the file es 644. I've tried chmod 777, and chown to Apache user, without positive results.

And what drives me crazy: if I copy the file, then rename old file and rename new file, it works!

mv image.gif image.gif.bak
cp image.gif.bak image.gif

Files are identical, same size, same permissions, same owner and group. I can see both in a imageviewer. But, if I restore original file (remove the "new" file and rename the "old" file to its original name) I got a "permission denied" again:

rm image.gif
mv image.gif.bak image.gif

This issue occurs with all image files, but not with text files (static html, css...).

What could be causing this strange behavior?

I'm using Apache 2.2.3 under CentOs 5.5. Perl scripts (Perl 5.8.8) runs with Suexec.

share|improve this question
    
Is selinux enabled? –  Mark Wagner Dec 9 '10 at 18:21
    
Yes embobo, that was the problem: a little mess with SELinux contexts. –  ARemesal Dec 10 '10 at 9:10
add comment

3 Answers

up vote 2 down vote accepted

I suspect that perhaps SELinux is causing problems? Disable it and see things start working:

su -
/sbin/setenforce 0

If things worked after disabling it, try restorecon and re-enable SELinux to see if maybe your SELinux contexts were screwed up.

share|improve this answer
    
Yeah, that was the problem! I'm not familiarize with SELinux nor CentOS (usually use Debian/Ubuntu Server) so I didn't think about it. In addition, the install script has messed up with file contexts, some of them didn't get repaired with restorecon, but can repair them with chcon. I'm going to read more about SELinux.Thanks JeffG! –  ARemesal Dec 10 '10 at 9:06
add comment

It really sounds like you have a permission problem due to

  • Using suexec, meaning that the CGI script and Apache do/may not run under the same user/group
  • I don't see in your description that you checked the path up to the image file, not only the file itself

suexec will have the script executed under the owner user and groups of the script. Apache itself will keep loading files using its own user/group as defined in httpd.conf (or apache[2].conf, conf.d/...).

  • Perform a ls -d of the path directories up to the images files, to ensure Apache has at least a --x access (no view, but access to named file).
  • You can give access a directory to Apache by changing the group to the Apache group (search Group in the configuration files) with chgrp apache-group directory, and adding the x access to that same directory chmod g+x directory.
share|improve this answer
    
Sorry, I didn't write about it. Apache is member of the user who runs suexec, permissions are OK and the path is OK. The problem was in SELinux. Thank you ring0! –  ARemesal Dec 10 '10 at 9:09
add comment

Do you have mime types in apache setup for the image files? Can you do the command ls -l in the directory your looking at and paste the output here.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.