RE: [PHP] Why PHP reads local php.ini?

To those who may concern, :-) http://bugs.php.net/bug.php?id=22001 It was a known, not documented bug. But they are not going to solve it!!!!. I can´t understand. Thanks everybody who answer me. -----Mensaje original----- De: Joel Rees [mailto:joel@alpsgiken.gr.jp] Enviado el: lunes 7 de abril de 2003 4:14 Para: php-general@lists.php.net CC: Jose Luis Perez Ruiz Asunto: Re: [PHP] Why PHP reads local php.ini? I assume you won't mind my keeping this on the list. (If the list server will believe that I'm really signed up.) > Maybe you misunderstood my question or maybe I didn´t explain you > everything. Anyway, thank you very much. You are the only one who answer me, > :-). I hope someone who knows more than I can pick this up. > Ok, let´s try to explain my plataform. I have an Apache that serves many > virtualHosts. I use suexec to control that cgi´s are run in the jail where > all virtualhost are. Each virtualhost has a different uid , and CGI´s are > run with it´s own uid. This way I can restrict my customer´s security and > privacy. And that´s why it´s so important that PHP is run as CGI. Okay, so you are a couple of steps ahead of me. > I have compiled PHP with '--with-config-file-path=/etc' option. It worked > correctly in the jail and I have a correct php.ini in '/etc'. In fact, PHP > first look './php.ini' and then if it doesn´t exists, it reads > /etc/php.ini. ( I used strace to see it ). This does not agree with what is described in the docs. I'm not a developer, but it sounds like a bug to me. Then again, my experience is mostly with mod_php, so I may have missed something in the docs about CGI mode. > I need PHP to run as a CGI, > because I use it in Apache and I need it to generate HTML code, so I can´t > compile it to work as CLI. Have you considered mod_php? Can you use it? Have you tried it? And does it have the same behavior? > I know that when you use -c option you can tell PHP where to look for > php.ini, but when you run PHP in CGI mode, it overrides command line > options. Hmm. So is the problem actually that your cgi scripts are specifying their own command line options? With Perl, there would be the problem of the shebang line, but I don't remember if php cgi allows a shebang line. > It´s a security matter. Yes. > I use PHPRC to tell PHP where to look for > php.ini for each of my virtualhosts, but when exists a php.ini file in the > directory where the scripts resides PHP read it and ignore PHPRC, -c or > compilation options. I'm still thinking you have some basic but non-standard option set somewhere to cause this behavior. Well, anyway, you may want to post your question to php.dev. Worst comes to worst, you may need to tweak the code and re-compile. I suspect that most of the people on this list, including me, don't have the expertise to help you with this. -- Joel Rees <joel@alpsgiken.gr.jp> > Feel free to ask any further information you need, and of course thanks in > avdvance. > > > -----Mensaje original----- > De: Joel Rees [mailto:joel@alpsgiken.gr.jp] > Enviado el: viernes 4 de abril de 2003 12:55 > Para: Jose Luis P駻ez Ruiz > Asunto: Re: [PHP] Why PHP reads local php.ini? > > > Relevant links: > http://www.php.net/manual/en/configuration.php > > http://www.php.net/manual/en/faq.installation.php#faq.installation.phpini > http://www.php.net/manual/en/features.commandline.php > > > I have compiled PHP with '--with-config-file-path=/etc' option. It worked > and I have a correct php.ini in '/etc'. In fact, PHP first look './php.ini' > and then if it doesn´t exists, it reads /etc/php.ini. I need PHP to run as > a CGI, because I use it in Apache and I need it to generate HTML code, so I > can´t compile it to work as CLI. > > > > > I mean than when you run PHP in CGI mode, PHP doesnエt read default > php.ini > > location. It first to look php in your actual path. An example... > > > > ecazfe04:/home3/www# php -v > > PHP 4.3.1 (cgi), Copyright (c) 1997-2002 The PHP Group > > Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies > > > > > > ecazfe04:/home3/www# export REQUEST_METHOD="POST" > > // Now we are in CGI mode as if it was called from Apache. > > > > ecazfe04:/home3/www# export REDIRECT_STATUS="200" > > // To avoid force-cgi-redirect > > > > ecazfe04:/home3/www# php -v > > Content-type: text/html > > X-Powered-By: PHP/4.3.1 > > > > No input file specified. > > // Ok, we are in CGI mode and it looks for a file. > > > > /home3/www# cd <path_to_file> > > /home3/www# php index.php > > Everithings gos OK, except that if exists php.ini in <path_to_file> > PHP > > uses it. That overrides default compilation option. You can see it if you > > use phpinfo() in 'index.php'. > > The faq listed above says that apache will look first in its own > installation directory, so you can have a different php.ini for each > apache you have running. > > It also says you can specify the location with a command-line switch, -c. > > > I think this shouldnエt be the correct way of reading php.ini, but > maybe > > Iエm wrong. Can anybody help me? I run a webserver (Apache+PHP) that hosts > > some virtualhosts and I donエt wonエt that my customers could use an > alternate > > php.ini. > > Well, if they can install their own apache, you're going to have a hard > time keeping them from using an alternate php.ini. > > I suggest that you configure apache to serve your customers from > directories somewhere outside the path to apache. That would be safer. > Look at these directives in httpd.conf: > > Alias > Directory > > and maybe > > UserDir > > For instance > > Alias /user1 "/home/user1/www" > > and > > <Directory "/home/user1/www"> > Options Indexes > AllowOverride None > Order allow,deny > Allow from all > DefaultLanguage es > </Directory> > > You probably don't want to use those, but that might give you the idea. > > Of course, if you're talking about letting your customers serve the web > from the shell, apache settings won't do you much good, and I think > you'll have more to worry about than whether or not they are using you > php.ini. > > > PS: Sorry, Iエm Spanish and I donエt know if my explanation is clear > > enough. > > Apologies if I misunderstood your question. > > -- > Joel Rees <joel@alpsgiken.gr.jp>