nginx: add http.sock mapping to enable customize web server for each user

[mayli]

ref: https://is.gd/YEXT7X

This patch only contains changes for <user>.<server>.hashbang.sh -> http.sock mapping, The hashbang.sh/~<user> -> ~user/Public was removed due to security reasons. The https changes will be posted in a separated patch after we finalize the nginx build we use.

[RyanSquared]

is there a reason port 443 is not enabled?

[RyanSquared]

To quote @lrvick:

add nginx repo and key, pin 1.10

As well as the above requested changes and allowing passthrough of raw TCP, that needs to be done as well.

References:

• http://nginx.org/packages/debian/
• http://stackoverflow.com/questions/34741571/nginx-tcp-forwarding-based-on-hostname

[KellerFuchs]

@RyanSquared No, nginx.org has a too-old version.

In any case, OK for me to go forward with HTTP-only and switch to a newer Nginx later on.

[daurnimator]

The hashbang.sh/~ -> ~user/Public was removed due to security reasons.

What were these security reasons?

[RyanSquared]

@daurnimator - race conditions with symlinks: there's no way to ensure that a file hasn't changed since you've checked the permissions, and made sure it's safe to load, before loading it.

[daurnimator]

@daurnimator - race conditions with symlinks: there's no way to ensure that a file hasn't changed since you've checked the permissions, and made sure it's safe to load, before loading it.

huh? which symlink? why are we checking permissions? (Shouldn't we just be attempting to serve ~/Public. and if it is accessible by the 'www' user then it will work)

[KellerFuchs]

@daurnimator Imagine you just blindly serve the contents of ~/Public. What prevents me from putting under my ~/Public a symlink to /some/readable/file/like/private.key ?

Also, it forces user to set mode 0711 (at least) on their homedir, which can be nasty.

Lastly, it forces us to do annoying cert handling server-wide or have a wildcard for *.hashbang.sh if we ever want to provide TLS for ~/Public that way.

[daurnimator]

What prevents me from putting under my ~/Public a symlink to /some/readable/file/like/private.key ?

If a file anywhere on the system is accessible by the user/group "www" then you should assume it's accessible to the web. Is private.key readable by the www user?

Also, it forces user to set mode 0711 (at least) on their homedir, which can be nasty.

Howso? And don't we already do this? I remember setting it up before.

Lastly, it forces us to do annoying cert handling server-wide or have a wildcard for *.hashbang.sh if we ever want to provide TLS for ~/Public that way.

I thought ~/Public was going to be served from <host>.hashbang.sh/~user

[RyanSquared]

If a file anywhere on the system is accessible by the user/group "www" then you should assume it's accessible to the web. Is private.key readable by the www user?

Shouldn't it be? The www user needs to be able to load it, no?

Howso? And don't we already do this? I remember setting it up before.

:+1:, still not sure why this is required.

I thought ~/Public was going to be served from .hashbang.sh/~user

That is correct.

[RyanSquared]

@daurnimator - found this: https://unix.stackexchange.com/a/13891

[daurnimator]

Shouldn't it be? The www user needs to be able to load it, no?

I thought it would load the private key before changing to the www user. But now I'm not so sure.

[KellerFuchs]

@daurnimator You can read memory or file descriptors from /proc too, it's kinda tricky.

[daurnimator]

@daurnimator You can read memory or file descriptors from /proc too, it's kinda tricky.

Ah I didn't think of that. Sounds tricky indeed.

[daurnimator]

What about https://nginx.org/en/docs/http/ngx_http_core_module.html#disable_symlinks ?

[daurnimator]

@KellerFuchs thoughts around that disable_symlinks option?

[KellerFuchs]

@daurnimator It's unclear whether it avoids the classic fstatat/open race condition...

[RyanSquared]

Presumably you wouldn't need fstatat() for this; you could just use open(<path>, O_NOFOLLOW). If nginx doesn't do this, then it's a bug with nginx and should be fixed.

[KellerFuchs]

@RyanSquared O_NOFOLLOW only prevents the last component of the path from being a symlink. i.e., if /home/kellerfuchs/foo is a symlink to /proc, I can totally make it open /home/kellerfuchs/foo/self/mem and other exciting things.

[RyanSquared]

Oh. :(

[mayli]

So, what about we have the sock files at single dir and let nginx chroot to that dir?

[daurnimator]

@daurnimator It's unclear whether it avoids the classic fstatat/open race condition...

See http://hg.nginx.org/nginx/file/4a670c18e5e6/src/core/ngx_open_file_cache.c#l500

[KellerFuchs]

@mayli I was replying to a question about serving ~/Public from Nginx directly. We don't have any problem with the socket solution, since users cannot create (arbitrary) symlinks where Nginx expects the sockets.

[KellerFuchs]

@daurnimator This looks safe enough: it's still racy, but enforcing same-ownership should be enough in our case (as only the owner should be able to write to ~/Public anyhow)