To determine if your script is running and what user and group it runs as, you might have it write to STDERR and add a long sleep. Output to STDERR should appear in the web server error log. While it is sleeping you can inspect the process with ps to determine security context. If nothing appears in the error log and you can't see the process with ps, then the script is probably not running at all, in which case suexec and selinux appear to be your prime suspects.

If suexec is running, the web server error log should have something like the following each time the server starts:

[notice] suEXEC mechanism enabled (wrapper: /path/to/suexec)
[download]

If it is running, there should be a log file: suexec_log in the web server log directory, by default. This should indicate the problem if suexec is refusing to run your script. Note that with suexec the user and group your script runs as may be specified by an SuexecUserGroup directive in the apache configuration.

The sestatus command will tell you whether selinux is running and enforcing, with output similar to the following:

[root@localhost ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted
[download]

On my system, it says:

[root@localhost ~]# sestatus
SELinux status:                 disabled
[download]

I have selinux disabled, but I understand that as of RHEL/CentOS 5, messages are written to the audit logs rather than /var/log/messages and the setroubleshoot command is supposed to be make reviewing the logs easy. http://www.linuxtopia.org/online_books/centos5/centos5_administration_guide/centos5_rhlcommon-chapter-0017.html might be helpful.