next »

[rnpnj]

I've tried everything I can think of or find documented.   When I run debug. pl, I get back:
"There was a problem creating a temp file in the 'session' directory.  Make sure that the directory has correct permissions!.
The error was: Permission denied"

Environment is Fedora/Apache (current releases).

/var/www/cgi-bin and all subordinate directories and files are owned by apache:apache (matches user:group Apache is run under) and permissions of 777.

I've tried moving the calendarscript directory outside the cgi-bin directory and even outside the www directory, making the appropriate changes to $BASE_DIR, with the same results.

In each case, however, I have tried running the script from the command line using su with any valid user name.   In every case, the debug. txt file is created with the appropriate owner.

Any thoughts on what I am missing will be appreciated, especially since my boss wants our new site up in three days.

[DanO]

** I have tried running the script from the command line using su with any valid user name.   In every case, the debug.txt file is created with the appropriate owner. Any thoughts on what I am missing **

I would say incorrect permissions or incorrect file/directory ownership.

Not all servers allow files or directories to be chmod 777 as it is a security risk. The most that should be needed for the CalendarScript data directories is 666 (or 766 if you're not a fan of the devil).

** directories and files are owned by apache:apache **

Usually scripts are run under a particular user but check with the system administrator as servers are not my specialty.

JMO

Dan O.

[rnpnj]

Solution Found -

In this case, I am the system administrator hosting my own box and in normal circumstances, with the permissions and ownerships I have set up, there should be no problem opening a file.

However under this version of Fedora and perhaps other versions of Linux, a feature called selinux, which is enabled by default, provides additional security to the system by restricting what daemons such as Apache can do (important little things like creating or writing to files).   I am not familiar enough with the details of selinux to determine what changes can be made to permit CalendarScript to do what it needs to do while still maintaining the rest of the selinux security.

I did find that disabling selinux entirely (change the value of SELINUX to disabled in /etc/selinux/config and reboot) resolved the problem.