You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/09/06 05:15:37 UTC
[PATCH] Fix relative internal file...
$.10 hack. Works for me.
The other solutions would require a rewrite of the logic. That
is something I don't have time to do and I also bet that OtherBill
has ideas about how to fix this the "right way." Or not. =-)
-- justin
Index: server/request.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/request.c,v
retrieving revision 1.48
diff -u -r1.48 request.c
--- server/request.c 2001/09/01 05:21:16 1.48
+++ server/request.c 2001/09/06 03:11:00
@@ -1581,9 +1581,7 @@
* either, if the base paths match, we can pick up where we leave off.
*/
- if (strncmp(rnew->filename, fdir, fdirlen) == 0
- && rnew->filename[fdirlen]
- && ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
+ if (strncmp(rnew->filename, fdir, fdirlen) == 0 && rnew->filename[fdirlen])
{
char *udir = ap_make_dirstr_parent(rnew->pool, r->uri);
Re: [PATCH] Fix relative internal file...
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 05, 2001 at 09:10:01PM -0700, Ian Holsman wrote:
> Cliff Woolley wrote:
> > On Wed, 5 Sep 2001, Greg Stein wrote:
> >>I don't understand what you're trying to solve here, and how this
> >>solves it.
> >
> > It's an attempt to fix the mod_include <!--#include file="foo/bar.html"-->
> > segfault. It "solves" it by setting r->uri to something valid rather than
> > setting it to "INTERNALLY GENERATED...". It's as yet unclear as to
> > whether it's a correct solution, though. I'm looking into it.
> >
> > --Cliff
>
> If the request is always relative to where we are,
> and we know the URI where we are... couldn't we generate the URI
> correctly ??? apr_pstrcat(r->uri, '/',file,NULL) ???
Maybe the specified file does not have a corresponding URI.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] Fix relative internal file...
Posted by Ian Holsman <ia...@cnet.com>.
Cliff Woolley wrote:
> On Wed, 5 Sep 2001, Greg Stein wrote:
>
>
>>I don't understand what you're trying to solve here, and how this
>>solves it.
>>
>
> It's an attempt to fix the mod_include <!--#include file="foo/bar.html"-->
> segfault. It "solves" it by setting r->uri to something valid rather than
> setting it to "INTERNALLY GENERATED...". It's as yet unclear as to
> whether it's a correct solution, though. I'm looking into it.
>
> --Cliff
>
If the request is always relative to where we are,
and we know the URI where we are... couldn't we generate the URI
correctly ??? apr_pstrcat(r->uri, '/',file,NULL) ???
Re: [PATCH] Fix relative internal file...
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 5 Sep 2001, Greg Stein wrote:
> I don't understand what you're trying to solve here, and how this
> solves it.
It's an attempt to fix the mod_include <!--#include file="foo/bar.html"-->
segfault. It "solves" it by setting r->uri to something valid rather than
setting it to "INTERNALLY GENERATED...". It's as yet unclear as to
whether it's a correct solution, though. I'm looking into it.
--Cliff
Re: [PATCH] Fix relative internal file...
Posted by Greg Stein <gs...@lyra.org>.
I don't understand what you're trying to solve here, and how this solves it.
Cheers,
-g
On Wed, Sep 05, 2001 at 08:15:37PM -0700, Justin Erenkrantz wrote:
> $.10 hack. Works for me.
>
> The other solutions would require a rewrite of the logic. That
> is something I don't have time to do and I also bet that OtherBill
> has ideas about how to fix this the "right way." Or not. =-)
> -- justin
>
> Index: server/request.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/server/request.c,v
> retrieving revision 1.48
> diff -u -r1.48 request.c
> --- server/request.c 2001/09/01 05:21:16 1.48
> +++ server/request.c 2001/09/06 03:11:00
> @@ -1581,9 +1581,7 @@
> * either, if the base paths match, we can pick up where we leave off.
> */
>
> - if (strncmp(rnew->filename, fdir, fdirlen) == 0
> - && rnew->filename[fdirlen]
> - && ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
> + if (strncmp(rnew->filename, fdir, fdirlen) == 0 && rnew->filename[fdirlen])
> {
> char *udir = ap_make_dirstr_parent(rnew->pool, r->uri);
>
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] Fix relative internal file...
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 5 Sep 2001, Justin Erenkrantz wrote:
> On Wed, Sep 05, 2001 at 11:34:24PM -0400, Cliff Woolley wrote:
> > hack did. Both will break if you have a relative path that goes UP at
> > least one directory first, since the strncmp will fail. You'll get back
>
> At least with mod_include, that can never happen. It makes sure that
> there are no ../ (or whatever for that OS) in a file directive.
Hmmm... thought required. That else case HAS to be there for a reason.
I'll do some research.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: [PATCH] Fix relative internal file...
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 05, 2001 at 11:34:24PM -0400, Cliff Woolley wrote:
> hack did. Both will break if you have a relative path that goes UP at
> least one directory first, since the strncmp will fail. You'll get back
At least with mod_include, that can never happen. It makes sure that
there are no ../ (or whatever for that OS) in a file directive.
-- justin
Re: [PATCH] Fix relative internal file...
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 5 Sep 2001, Justin Erenkrantz wrote:
> $.10 hack. Works for me.
>
> The other solutions would require a rewrite of the logic. That
> is something I don't have time to do and I also bet that OtherBill
> has ideas about how to fix this the "right way." Or not. =-)
>
> - if (strncmp(rnew->filename, fdir, fdirlen) == 0
> - && rnew->filename[fdirlen]
> - && ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
> + if (strncmp(rnew->filename, fdir, fdirlen) == 0 &&
>rnew->filename[fdirlen])
This won't work, I'll bet, for the same reason my hack won't work. All
you've done is cause the mod_include httpd-test test to pass by getting it
into the "then" instead of the "else", which is the exact same thing my
hack did. Both will break if you have a relative path that goes UP at
least one directory first, since the strncmp will fail. You'll get back
into the else case and segfault again. Rather than working around the
else, which is there for a reason, we need to patch the REST of the code
to be aware of the existance of the else case. The easiest way to do that
is probably to change the else case to set r->uri NULL instead of to
"INTERNALLY GENERATED fooness" and test r->uri before using it in all
places it's used.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA