2
votes

I'm having this problem and I reached a deadlock, I would try anything I've reached a deadend. My problem goes like this:

I have a Perl/CGI script installed on Fedora 9 machine running apache2, this script have a config file which placed in the same directory, this config file has 777 permissions.

The script can't write to the file. It can read but in no way could I get it to write to it. The file is owned by the same user the apache is running. I wrote a small PHP script to test and placed it in the same folder. The PHP script can read but can't write to it.

I'm so desperate here and I don't know where to start with problem, so any help to get me on the right way would be appreciated.

EDIT: I can open the file for editing from command line; it is apache who can't access it

EDIT2: the folder hierarchy /var/www/cgi-bin/script
permissions are like this
/var root 755
www root 755
cgi-bin root 755
script apache 755

EDIT: The problem was in selinux. I disabled it and the script had access to the file thanks for everyone contributed

Thanks in advance

5

5 Answers

12
votes

Does apache run with some selinux profile or similar that prevents it writing in that directory?

3
votes

The user apache probably doesn't have permission to one of the parent directories. It needs to have at least execute permission in all of the directories up to and including the directory that contains your file.

EDIT: Right, considering this is a programming site, some code might be in order.

  1. Use the absolute path to the file to test, not the relative one to make sure you're in the right directory.

  2. $! should print out a "Permission Denied" error if it is permissions, can you print out the problem with:

    open(FILE, ">/path/to/file/config.ini") || die "Cannot open: $!"; ... close(FILE);

2
votes

Maybe some other process has a write lock to file? Try lsof to see who is holding it open.

2
votes

Does the directory allow permission for the webserver to write files there?

0
votes

I know that a previous post touched on this, but I think it bears repeating: When discussing a problem of this nature it's helpful to include the relevant code and the output of the exception. If an I/O operation fails, $! should contain the system error message, which would explain why the operation failed. Saying "it didn't work" doesn't really give us anything to go on.