You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Axel Beckert <ax...@dagstuhl.de> on 2001/11/16 11:16:18 UTC
mod_include/8772: SSI #exec cmd="..." doesn't work anymore (but worked in 2.0.16 beta)
>Number: 8772
>Category: mod_include
>Synopsis: SSI #exec cmd="..." doesn't work anymore (but worked in 2.0.16 beta)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apache
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Fri Nov 16 02:20:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: axel@dagstuhl.de
>Release: 2.0.28-dev CVS, 2.0.28 beta
>Organization:
apache
>Environment:
uname -a:
FreeBSD cip117.studcs.uni-sb.de 4.2-RELEASE FreeBSD 4.2-RELEASE #11: Wed Aug 22 09:45:09 CEST 2001 i386
gcc -v:
gcc version 2.95.2 19991024 (release)
>Description:
I upgrade from 2.0.16 beta to 2.0.28-dev from CVS about two weeks ago and have update to 2.0.28 beta a few days ago.
Both 2.0.28 versions just ignore the SSI command #exec cmd="/bin/foo" in the way, that it's just absorbed. Neither in the error log nor in the documentation /bug database I found a note on this strange behaviour. Also a fast look over the diff on both mod_include.c versions didn't help (at least to me :-). And the only thing, I found in the CHANGES file I was an entry which states, that SSI command #exec *cgi* has been changed to work also on win32 platforms, but not the #exec cmd command.
The SSI command #exec cgi="/cgi-bin/foo.cgi" still does work.
>How-To-Repeat:
http://cip117.studcs.uni-sb.de:8042/ doesn't show the two "uname -foo" commands embedded in the page since I update from 2.0.16 to 2.0.28-dev on that machine. But the fortune-like CGI script (embedded via #exec cgi) issuing another joke or saying on each request still works fine. (This server is just for playing around and not for performance. It will probably disappear at the end of the year. :-)
>Fix:
Sorry, not yet.
>Release-Note:
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, you need]
[to include <ap...@Apache.Org> in the Cc line and make sure the]
[subject line starts with the report component and number, with ]
[or without any 'Re:' prefixes (such as "general/1098:" or ]
["Re: general/1098:"). If the subject doesn't match this ]
[pattern, your message will be misfiled and ignored. The ]
["apbugs" address is not added to the Cc line of messages from ]
[the database automatically because of the potential for mail ]
[loops. If you do not include this Cc, your reply may be ig- ]
[nored unless you are responding to an explicit request from a ]
[developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]
Re: mod_include/8772: SSI #exec cmd="..." doesn't work anymore (but worked in 2.0.16 beta)
Posted by Axel Beckert <ab...@cs.uni-sb.de>.
Hi!
On Tue, Nov 20, 2001 at 10:45:30AM -0600, William A. Rowe, Jr. wrote:
> Here's where we are going wrong. #exec cmd="/bin/uname" should work
> just fine.
Sorry, but it doesn't. The mentioned page
http://xcip3.studcs.uni-sb.de:8042/
now has the three following commands and none of them works, all are
absorbed:
<!--#exec cmd="/usr/bin/uname -rs" -->
<!--#exec cmd="/usr/bin/uname -m" -->
<!--#exec cmd="/usr/bin/uname" -->
I set up a special page for this PR at
http://xcip3.studcs.uni-sb.de:8042/8772.shtml,
where all the mentioned issues are shown. There you also can get all
source codes of the used SSI documents and the used CGI script.
There is another problem reagrding SSIs which is mentioned on that
page and especially on the two pages
http://xcip3.studcs.uni-sb.de:8042/8772-2.shtml and
http://xcip3.studcs.uni-sb.de:8042/8772-3.shtml.
The output of the three CGI date variables seems to some format string
errors and contain binary garbage or values of other variables, and
that depends somehow on if there are #exec or #printenv in the SSI
file or not.
HTH.
Regards, Axel
--
Axel Beckert - abe@cs.uni-sb.de - http://abe.home.pages.de/
Student of Computer Science, University of Saarland (Germany)
Artificial Intelligence Laboratory (AI Lab), Prof. Dr. W. Wahlster;
WWW-/FTP-Administrator IBFI Schloß Dagstuhl; Students Representative CS
Re: mod_include/8772: SSI #exec cmd="..." doesn't work anymore (but
worked in 2.0.16 beta)
Posted by Cliff Woolley <jw...@apache.org>.
> > Here's where we are going wrong. #exec cmd="/bin/uname" should work
> > just fine. #exec cmd="/bin/uname -foo" is probably what's broken.
Wait a minute, time out. No. <!--#exec cmd="echo pass"--> is the test I
added to httpd-test yesterday. That works for me! I even just changed it
in my local copy to <!--#exec cmd="/bin/echo pass"-->, and it still works:
# testing : GET /modules/include/exec/off/cmd.shtml
# expected: '[an error occurred while processing this directive]'
# received: '[an error occurred while processing this directive]'
ok 8
# testing : GET /modules/include/exec/on/cmd.shtml
# expected: 'pass'
# received: 'pass'
ok 9
--Cliff
Re: mod_include/8772: SSI #exec cmd="..." doesn't work anymore (but
worked in 2.0.16 beta)
Posted by Cliff Woolley <jw...@apache.org>.
On Tue, 20 Nov 2001, William A. Rowe, Jr. wrote:
> Here's where we are going wrong. #exec cmd="/bin/uname" should work
> just fine. #exec cmd="/bin/uname -foo" is probably what's broken.
>
> Good catch, thanks for mentioning that 'argument' in the note.
Ohhhhhhhhh... Now I get it. :) Thanks Bill!
--Cliff
Re: mod_include/8772: SSI #exec cmd="..." doesn't work anymore (but worked in 2.0.16 beta)
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Axel Beckert" <ax...@dagstuhl.de>
Sent: Friday, November 16, 2001 4:16 AM
> Both 2.0.28 versions just ignore the SSI command #exec cmd="/bin/foo" in the way, that it's just absorbed. Neither in the error
log nor in the documentation /bug database I found a note on this strange behaviour. Also a fast look over the diff on both
mod_include.c versions didn't help (at least to me :-). And the only thing, I found in the CHANGES file I was an entry which states,
that SSI command #exec *cgi* has been changed to work also on win32 platforms, but not the #exec cmd command.
>
> The SSI command #exec cgi="/cgi-bin/foo.cgi" still does work.
> >How-To-Repeat:
> http://cip117.studcs.uni-sb.de:8042/ doesn't show the two "uname -foo" commands embedded in the page since I update from 2.0.16 to
2.0.28-dev on that machine. But the fortune-like CGI script (embedded via #exec cgi) issuing another joke or saying on each request
still works fine. (This server is just for playing around and not for performance. It will probably disappear at the end of the
year. :-)
Here's where we are going wrong. #exec cmd="/bin/uname" should work just fine.
#exec cmd="/bin/uname -foo" is probably what's broken.
That feature was broken forever and a year, if you query for ssi exec and suexec
you will see this bug repeated over and over.
We probably need to review the syntax overall, since the argv[0]/command are now
based on a literal interpretation of the cmd or (filesystem mapped) cgi argument.
Good catch, thanks for mentioning that 'argument' in the note.
Bill