How do you set ORACLE_HOME and did you set any other environment variables?
Is ORACLE_HOME dir readable by the user httpd uses for its childs?
What do you mean by "patched oci8.c"?

ORACLE_HOME was set in /etc/sysconfig/httpd along with...

ORACLE_BASE=/opt/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/10.2.0/db_1; export ORACLE_HOME
TNS_ADMIN=$ORACLE_BASE/product/10.2.0/db_1/network/admin; export TNS_ADMIN
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH

(As an aside, I experimented with these variables and *BELIEVE* ORACLE_HOME was the only one necessary, but I was running the CLI version)

ORACLE_HOME permissions are set to 755.

The patch to oci8.c consisted of adding...

 php_error_docref(NULL TSRMLS_CC, E_WARNING, getenv("ORACLE_HOME"));

... just below ...

 php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP_OCI_INIT_FUNC_NAME "() failed. There is something wrong with your system - please check that ORACLE_HOME is set and points to the right directory");

... to report the actual value into the /var/log/httpd/error_log.  I then remade and installed PHP5.

Are you sure ORACLE_HOME is set *before you start* Apache?
Does PHP CLI work?

ORACLE_HOME is definitely being set before httpd is started.  The /etc/sysconfig/httpd script is sourced at the start of the httpd init script (I also echoed $ORACLE_HOME to make sure).

PHP CLI does connect successfully and now I believe I know why...

The issue appears to be related to permissions and I am quickly getting out of my depth.  When I run the PHP CLI test, I am running as 'oracle' or in my developer account which, for convenience, is a member of the 'oinstall' group.  I added the 'oinstall' group to the 'apache' user ( usermod -Goinstall apache ) and was able to connect using the php5_module under apache.  Obviously, giving apache this level of access to the oracle installation is dangerous and shouldn't be necessary.  It suggests that the development of the oci8 extension may have been done with either a less secure Oracle installation or with an account having more Oracle privilege than it should.

Would it be appropriate for the oci8 extension developers to look into this security issue?

OCI8 extension itself doesn't require any variables, access privileges etc. Those requirements are set by oracle client libraries, so there is nothing we can do about it.
And personally I don't consider giving read permissions to apache user as dangerous.

But you can use Oracle Instant Client that doesn't require nor ORACLE_HOME (or any other variables) to be set, neither read privileges for any oracle directories.
See details here: http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html

No PHP bug -> bogus.

Do you really think that apache should be a member of the oracle group to run php5_module with OCI8?  A friend, who has been a consultant with Oracle for the last 10 years doesn't consider it kosher.  My client for whom I am developing a PHP/Oracle application doesn't particularly like the idea of a PHP script being able execute any Oracle binary it likes.

Instant client is designed for accessing remote database servers.  It may be the only way to provide the security needed.  I don't know but now will have to learn it to find out.  Clearly OCI8 as currently written is pretty useless for a production environment, at least if Oracle and Apache are on the same server.

>Do you really think that apache should be a member of 
>the oracle group to run php5_module with OCI8?  
It doesn't matter what I think about it, this is *required* by oracle client libraries.

>A friend, who has been a consultant with Oracle for the
> last 10 years doesn't consider it kosher. 
Why do you tell me this?
If you know how to avoid it (and still provide a way for OCI to read tnsnames.ora and other files) - tell it to Oracle people.

> My client for whom I am developing a PHP/Oracle 
> application doesn't particularly like the idea of a PHP 
> script being able execute any Oracle binary it likes.
Tell your client about open_basedir directive.
Also I think it would be worth to read about unix privileges. You don't have to grant to the user both execute and read privileges in the same time.

>Instant client is designed for accessing remote database servers.  
Wrong. It doesn't matter whether the server is local or not.

>I don't know but now will have to learn it to find out.  
Yes, do it please.

>Clearly OCI8 as currently written is pretty useless for a
>production environment, at least if Oracle and Apache are
>on the same server.
Please direct your complaints to Oracle, it has nothing to do with PHP or ext/oci8.

> It doesn't matter what I think about it, this
> is *required* by oracle client libraries.

Funny.  It didn't seem to be necessary with PHP5.0.4 and 10g Release 2.  But what do I know?

> Why do you tell me this?

Just to piss you off!  Maybe a couple of deep breaths next time.

> If you know how to avoid it (and still provide a way
> for OCI to read tnsnames.ora and other files) -
> tell it to Oracle people.

But wait!  You said that "OCI8 extension itself doesn't require any variables, access privileges
etc.".  Are you telling me that you need access to tsnames.ora or other resources?  If so, please elaborate and perhaps a more limited relaxation of security can be arranged.  Something that doesn't permit the execution of dbshut, for example.

> Also I think it would be worth to read about unix
> privileges. You don't have to grant to the user both
> execute and read privileges in the same time.

Really?  I wonder why I didn't know that :P  However, I still need to know what I need to provide access to for the "world", don't I?

>Wrong. It doesn't matter whether the server is local or not.

Of course!  But if you have Oracle Client installed you really don't need instant client, do you?  Except for security reasons.

>>I don't know but now will have to learn it to find out.  
>Yes, do it please.
And when you know everything we will all sing your praises, Hallelujah!

>Please direct your complaints to Oracle, it has nothing
>to do with PHP or ext/oci8.

Nothing, indeed!  But I believe I have beat my head against this enough for the time being.

>It didn't seem to be necessary with PHP5.0.4 and 10g Release 2. 
Yes, it's funny and everybody is laughing. Because _it is_ necessary for all versions of OCI libraries, except for the Instant Client.

>You said that "OCI8 extension itself doesn't require any 
>variables, access privileges etc.".  

ext/oci8 - PHP extension.
OCI - Oracle Call Interface libraries.
See the difference?

>Something that doesn't permit
>the execution of dbshut, for example.

JFYI: to run dbshut you need to do `su - oracle` first.

>I need to provide access to for the "world", don't I?
No?
And even if you would need it, what secrets are you trying to hide in your tnsnames.ora, huh?

>But if you have Oracle Client installed you really don't
> need instant client, do you?  Except for security reasons.
Well, _now_ it's funny. I thought you were so worried exactly because of security reasons.
And now you're saying you don't need it.
But why do I care?

The solution is configure envars the apache.

path: /usr/local/apache2/bin/envvars:

View example:

ORACLE_HOME=/usr/lib/oracle/10.1.0.3/client;export ORACLE_HOME
NLS_LANG=AMERICAN;export NLS_LANG
LD_LIBRARY_PATH=/usr/lib/oracle/10.1.0.3/client/lib;export LD_LIBRARY_PATH
LD_LIBRARY_PATH="/usr/local/apache2/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH