#1679 closed defect (wontfix)
php -s fails
Reported by: | xris | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | version control/browser | Version: | devel |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Using [1809], tried to view a php file, and I get:
Running (php -s) failed: 255, .
php -s
works fine when I run it on the command line (even as an unprivileged "apache" user, via sudo)
Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/trac/web/cgi_frontend.py", line 103, in run dispatch_request(os.getenv('PATH_INFO', ''), req, env) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 421, in dispatch_request dispatcher.dispatch(req) File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 285, in dispatch resp = chosen_handler.process_request(req) File "/usr/lib/python2.3/site-packages/trac/Browser.py", line 133, in process_request self._render_file(req, repos, node, rev) File "/usr/lib/python2.3/site-packages/trac/Browser.py", line 240, in _render_file annotations=['lineno']) File "/usr/lib/python2.3/site-packages/trac/mimeview/api.py", line 215, in render return self._annotate(result, annotations) File "/usr/lib/python2.3/site-packages/trac/mimeview/api.py", line 243, in _annotate for num, line in enum(_html_splitlines(lines)): File "/usr/lib/python2.3/site-packages/trac/util.py", line 42, in enum for item in iter(iterable): File "/usr/lib/python2.3/site-packages/trac/mimeview/api.py", line 259, in _html_splitlines for line in lines: File "/usr/lib/python2.3/site-packages/trac/mimeview/php.py", line 73, in render raise Exception, err Exception: Running (php -s) failed: 255, .
Attachments (0)
Change History (9)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Duplicate of #1676
Solution is to use source:/trunk/trac/mimeview/php.py#1620
A simple merge should do it but this is the complicated case where I am merging the trunk changes out of the anydiff branch. You'd want 1809 as your first revision number.
[root@summer mimeview]# svn merge -r1792:1620 http://svn.edgewall.com/repos/trac/trunk/trac/mimeview/php.py U php.py [root@summer mimeview]#
comment:3 by , 19 years ago
Resolution: | duplicate |
---|---|
Status: | closed → reopened |
comment:4 by , 19 years ago
Severity: | major → normal |
---|
xris, is this still happening with the current trunk? (e.g. r2012)
comment:5 by , 19 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
This has been open long enough without an answer that I think it's safe to assume it's working.
follow-up: 7 comment:6 by , 18 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
actually, i'm getting this problem as well - wonder what 255 error code with an empty string means from NaivePopen…
comment:7 by , 18 years ago
Replying to jkloske@itee:
actually, i'm getting this problem as well - wonder what 255 error code with an empty string means from NaivePopen…
Are you also using Apache-CGI? Do you get the same error if running tracd as the Apache user?
comment:8 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Ahh yes, I'm using the apache-cgi, which would explain it. I wrote a script to wrap the call to php through sed to add newlines after <br /> tags, like so:
#!/bin/bash cat > /tmp/phpsees.txt php -qsn < /tmp/phpsees.txt | sed -e 's/<br \/>/<br \/>\n/g'
What I saw when running this manually on the command line was syntax highlighted output like I would expect (via root, apache, any user account.)
Then I switched this for the php binary in trac.ini and tried to view a .php file and got this in the trac source browser:
Content-type: text/'''htmlSecurity Alert!''' The PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. Thismeans that a page will only be served up if the REDIRECT_STATUS CGI variable isset, e.g. via an Apache Action directive. For more information as to why this behaviour exists, see the [http://php.net/security.cgi-bin manual page for CGI security]. For more information about changing this behaviour or re-enabling this webserver,consult the installation file that came with this distribution, or visit
Seems the fancy php 'security' feature to stop it being run from inside apache on the command line is what's breaking this, since the trac cgi's copy the apache environment variables all the way down into php.
In fact:
# env SERVER_NAME=bob php -qsn Status: 400 Content-type: text/html <b>Security Alert!</b> The PHP CGI cannot be accessed directly. <p>This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive.</p> <p>For more information as to <i>why</i> this behaviour exists, see the <a href="http://php.net/security.cgi-bin">manual page for CGI security</a>.</p> <p>For more information about changing this behaviour or re-enabling this webserver, consult the installation file that came with this distribution, or visit <a href="http://php.net/install.windows">the manual page</a>.</p>
I really haven't had a chance to look much further at this (I just wrote a shell script last friday as a quick workaround that simply spat out non-highlighted code) so I may have missed something simple or misinterpreted stuff.
I tried doing what the php user comments suggested and temporarily setting REDIRECT_STATUS, but that didn't seem to work (it ignored the command line arguments, which kind of defeated the purpose.)
I guess the solution is to install the cli version of php and link to that instead from trac.ini.
Thanks again.
comment:9 by , 18 years ago
I should probably also point out:
- I changed the status of this ticket to "wontfix" because even though it'd be nice if trac was changed to deal with php-cgi installs properly, it's not necessary.
and
- Not sure if the security implications of doing so, but if you edit trac.ini and change the php_path variable to this:
php_path = /usr/bin/env -u GATEWAY_INTERFACE -u PATH_TRANSLATED -u REQUEST_METHOD -u SCRIPT_FILENAME -u SERVER_NAME -u SERVER_SOFTWARE /usr/bin/php -q
it seems to fool php enough that it works as a CLI mode binary. This was on a recent centos using the php-cgi from the standard yum repos, ymmv.
just to update, I tried hard-coding the path into trac.ini and I still get the same error.