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

Already on GitHub? Sign in to your account

Rack::Request#trusted_proxy? regex is too strict for unix socket #488

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants

Using Nginx + Phusion Passenger Standalone, the passed REMOTE_ADDR contains more then just unix. Often it contains unix: en sometimes unix:'+ other characters.

The regex to check trusted_proxy? is too strict for Passenger unix sockets.

Owner

raggi commented Jan 11, 2013

doesn't this allow unix.example.org?

probably wants to be ^unix:

@raggi raggi closed this in 9b8ab04 Jan 11, 2013

Thanks for making this change @raggi. I tried to find the originating source of the REMOTE_ADDR header, especially since I find the 'random' garbage suffix worrying.

Since Passenger just gets its value from Nginx: DEFINE_VAR_TO_PASS("REMOTE_ADDR", "$remote_addr");, I thought more people using Nginx and unix sockets would get these values for REMOTE_ADDR, but I could not find any other cases.

Perhaps @FooBarWidget can tell us why the Phusion Passenger Standalone passes unix: + random part of path as the REMOTE_ADDR HTTP header to Rack when binding to a unix socket.

Contributor

FooBarWidget commented Jan 14, 2013

There is a difference between Passenger for Nginx and Passenger Standalone. Passenger Standalone is implemented by starting Nginx+Passenger with specific settings. If Nginx listens on a Unix domain socket, then it sets REMOTE_ADDR to unix:/somewhere.

Since the reverse proxy link speaks the HTTP protocol, the frontend web server cannot pass REMOTE_ADDR information to Nginx except through HTTP headers such as X-Forwarded-For (which translates to the HTTP_X_FORWARDED_FOR CGI variable).

At the time Phusion Passenger was developed, we checked how other app servers behaved when they listened on Unix sockets. If I remember correctly Thin just sets REMOTE_ADDR to the empty string.

I am open to suggestions on how to solve this, if a solution is necessary.

Thanks Hongli, that makes perfect sense. Relying on HTTP_X_FORWARDED_FOR when using a reverse proxy is a fine and used in many places.

What still confuses me is that the somewhere part of unix:/somewhere seem rather random. The examples from related issue #353, show values as "unix:rent^D", "unix:-Compa^D" or "unix: 3.0.1^D".

I understand that this is probably implemented in Nginx.

Contributor

FooBarWidget commented Jan 18, 2013

Yes I believe that's an Nginx issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment