Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BZ-69203: backport to 2.4.x #470

Open
wants to merge 5 commits into
base: 2.4.x
Choose a base branch
from
Open

BZ-69203: backport to 2.4.x #470

wants to merge 5 commits into from

Conversation

ylavic
Copy link
Member

@ylavic ylavic commented Aug 1, 2024

  • r1919620
  • r1919621
  • r1919623
  • r1919628
  • r1921237

* If we have a raw control character or a ' ' in nocanon path,
* correct encoding was missed.
*/
if (path == url && *ap_scan_vchar_obstext(path)) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have we intentionally lost failing on spaces here? I guess the original intent was about splitting with CRLF?

Copy link
Member Author

@ylavic ylavic Sep 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, IIUC that's the issue reported in BZ-69203.
Before 2.4.60+ we didn't call proxy_fcgi_canon() for SetHandler URLs, so SCRIPT_FILENAME was never encoded. Now that we do, this PR applies "nocanon" for SetHandler URLs, and lets spaces through because supposedly they are not harmful in the SCRIPT_FILENAME env var (unlike in the uri-path for an HTTP request..).

if (rconf && rconf->need_dirwalk) {
char *saved_filename = r->filename;
r->filename = r->uri;
ap_directory_walk(r);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See https://lists.apache.org/thread/4gw6tsp0xlpdf3l9gtz1jnr5wzycsfg8:

Why not using the result of the below Strip proxy: prefixes for r->filename? In case of a Rewriterule I guess r->uri and r->filename could be fundamentally different path wise.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it helps to say a little about this obscure option to try to calculate PATH_INFO. It's meant/doc'ed for ProxyPass/ProxyPassMatch configurations where there was no mapping to FS hence no split off for PATH_INFO.

I don't think any of these proxy-fcgi-pathinfo options are widely used. I guess if r->filename had proxy: prefix stuff in it this was maybe useless since inception hence no users?

OTOH like you say, just peeling it all off as we will already do below would seem to give a better result assuming the user doesn't intend to keep some "original" PATH_INFO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not using the result of the below Strip proxy: prefixes for r->filename? In case of a Rewriterule I guess r->uri and r->filename could be fundamentally different path wise.

Done in [1] too, but this patch is not ready yet and will probably need more discussions (including with fpm maintainers..). I can take this bit from there though, will do!

[1] https://lists.apache.org/thread/vmz22tv2j8bz7vhw98hy3xwvqyp68cdc

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 7441bb4 for this, thanks!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll create another PR for this because this has nothing to do with BZ-69203 afterall..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #489

modules/proxy/mod_proxy_fcgi.c Outdated Show resolved Hide resolved
Before r1918550 (r1918559 in 2.4.60), "SetHandler proxy:..." configurations
did not pass through proxy_fixup() hence the proxy_canon_handler hooks, leaving
fcgi's SCRIPT_FILENAME environment variable (from r->filename) decoded, or more
exactly not re-encoded.

We still want to call ap_proxy_canon_url() for "fcgi:" to handle/strip the UDS
"unix:" case and check that r->filename is valid and contains no controls, but
proxy_fcgi_canon() will not ap_proxy_canonenc_ex() thus re-encode anymore.

Note that this will do the same for "ProxyPass fcgi:...", there is no reason
that using SetHandler or ProxyPass don't result in the same thing. If an opt
in/out makes sense we should probably look at ProxyFCGIBackendType.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1919620 13f79535-47bb-0310-9956-ffa450edef68
Variable from_handler is used once so axe it.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1921237 13f79535-47bb-0310-9956-ffa450edef68
@bastien-roucaries
Copy link

What is the ETA for this pull request ?

Copy link

@bukka bukka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have done some testing with FPM (those are the test cases: https://github.com/wstool/wst-php-fpm/blob/bf390dd1dda196ea9339b4d3d26caf5fbf306226/spec/instances/httpd-proxy-fcgi-handler-basic.yaml ) and the only change required is the different status code for ? in path which is actually for better as I mentioned in the comment. So this looks like a reasonable change to me. I haven't tested UDS yet though as I need to extend my testing framework a little bit for that.

ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(10414)
"To be forwarded path contains control characters%s (%s)",
FCGI_MAY_BE_FPM(dconf) ? " or '?'" : "", url);
return HTTP_FORBIDDEN;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a note that this changed from 404 to 403 (just tested the question mark case) compare to 2.4.59. But I think it's actually better error code now so should be fine.

Copy link

@bukka bukka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added similar tests for UDS and they all pass too. It seems to work fine so I think this is good to go from the PHP-FPM PoV.

asfgit pushed a commit that referenced this pull request Nov 25, 2024
mod_proxy_fcgi: Don't re-encode SCRIPT_FILENAME. PR 69203

Before r1918550 (r1918559 in 2.4.60), "SetHandler proxy:..." configurations
did not pass through proxy_fixup() hence the proxy_canon_handler hooks, leaving
fcgi's SCRIPT_FILENAME environment variable (from r->filename) decoded, or more
exactly not re-encoded.

We still want to call ap_proxy_canon_url() for "fcgi:" to handle/strip the UDS
"unix:" case and check that r->filename is valid and contains no controls, but
proxy_fcgi_canon() will not ap_proxy_canonenc_ex() thus re-encode anymore.

Note that this will do the same for "ProxyPass fcgi:...", there is no reason
that using SetHandler or ProxyPass don't result in the same thing. If an opt
in/out makes sense we should probably look at ProxyFCGIBackendType.



Follow up to r1919620: CHANGES entry indent.

Follow up to r1919620: init path after "proxy:" is skipped.

Follow up to r1919620: Restore r->filename re-encoding for ProxyPass URLs.



mod_proxy_fgci: Follow up to r1919628: Simplify.

Variable from_handler is used once so axe it.



Submitted by: ylavic
Reviewed by:   ylavic, covener, jorton

Github: closes #470


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1922080 13f79535-47bb-0310-9956-ffa450edef68
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants