Re: Passing ini settings via command line / session files permissions

From: Date: Mon, 21 Oct 2002 12:21:16 +0000
Subject: Re: Passing ini settings via command line / session files permissions
References: 1  Groups: php.general 
Request: Send a blank email to php-general+get-120720@lists.php.net to get a copy of this message
Have you tried setting this in .htaccess file Seb Wills wrote:
Hi, I've been trying to set an ini setting via the "-d" command line option to the PHP CGI executable, however I have fallen foul of the 'feature' that PHP ignores all command line options when invoked in a CGI environment. ("When invoked as a CGI binary, PHP refuses to interpret the command line arguments." - http://www.php.net/manual/en/security.cgi-bin.php). The reason I want to do this is as follows. I have a multi-user setup where the PHP binary is called from a wrapper which becomes the user who owns the file before executing php (it's not suExec, but does a roughly similar job). This creates the problem that PHP session files stored in /tmp are only writable by the particular user who owned the PHP file. So if you visit two sites on my server which both use PHP session cookies, you get an error because PHP receives the session cookie from the other site, and tries to update the corresponding session file (which is owned by another user and hence not writable to). Now, a solution would be for all my users to set the session.cookie_path parameter to restrict to their own URLs. Then the session cookies would never get passed back to PHP when it was executing another user's script. But since not all my users are likely to remember to do this (and since not doing so affects other users, not just them), I thought I would set up a default session.cookie_path in the wrapper. Because the required path varies according to who owns the php script, it can't be fixed in a php.ini file. Setting it on the command line would have been the perfect solution, but it doesn't work because of PHP's security checks! Any suggestions? I'm sure other users who use suExec in conjunction with PHP (CGI mode) must have encountered this problem... seb


« previous php.general (#120720) next »