[Feature]: Support setting unix socket listener file mode about oauth2-proxy HOT 8 OPEN

systemd-socket-activate is a standalone program that you can prepend to oauth2-proxy also.

Oh, neat!

What's funny is that systemd-socket-activate does not have support for changing mode :-).

Oh come on... sigh... 😂

Well, I guess both patches still make sense then... sigh...

from oauth2-proxy.

Systemd is no way a hard requirement for #1985, just as long as you set LISTEN_FDS=1 LISTEN_PID=2 and --http-address=fd:3 you should be fine (provided there an actual listening socket on fd 3).

systemd-socket-activate is a standalone program that you can prepend to oauth2-proxy also. It's quite easy to replicate it also.
systemd-socket-activate -l /tmp/socket <oauth2-proxy> would start the process when there's traffic on the socket. What's funny is that systemd-socket-activate does not have support for changing mode :-).

Hence I do think that adding mode= to http-address would make sense for unix addresses.

For my part it's pretty much solved with the systemd support and a systemd.socket, as long as the socket has mode 0660 and group www-data, nginx have no problem accessing it. The problem with the patch seems to be very much some odd problem in Go when listening on new sockets, but it's mostly causing problems in tests.

from oauth2-proxy.

Also, you could use /lib/systemd/systemd-socket-proxyd. It will start on it's own.

oauth2-proxy-forward.socket

[Socket]
ListenStream=/run/oauth2-proxy-forward/oauth2-proxy.sock
SocketGroup=www-data
SocketMode=0660
Accept=no

[Install]
WantedBy=sockets.target

oauth2-proxy-forward.service

[Service]
User=oauth2-proxy
ExecStart=/lib/systemd/systemd-socket-proxyd /run/oauth2-proxy/oauth2.sock

from oauth2-proxy.

Well, I never knew. That certainly solves the issue for me (have to check that it works nicely but I see no reason why it wouldn’t :)

from oauth2-proxy.

For others maybe looking into this problem for similar reasons (unprivileged reverse proxy user calling oauth2-proxy's socket), abstract unix sockets happen to do the job fine:

# oauth2-proxy.toml

http_address = "unix://@oauth2-proxy"
# ...
skip_auth_routes = ["^/ping", "^/metrics"]
# ...

$ sudo -u unprivileged-user \
  curl -I --abstract-unix-socket oauth2-proxy http://foo/ping

HTTP/1.1 200 OK
Date: Wed, 06 Mar 2024 02:47:33 GMT
Content-Length: 2
Content-Type: text/plain; charset=utf-8

So, assuming your reverse proxy can use these, you then don't need to worry about permissions or filepaths

from oauth2-proxy.

Isn't that the same though as allowing it to the whole system?
You might want to investigate PrivateIPC etc.

from oauth2-proxy.

Isn't that the same though as allowing it to the whole system?

It is allowing the whole system to send requests to oauth2-proxy, yes. Which is not entirely ideal, but a better tradeoff still than allowing the reverse proxy to access all the files that oauth2-proxy can.

I'd also note that when using TCP listeners, the problem is the same, unless you dedicate network namespaces to all your processes etc, so it is more like "same semantics as TCP listeners, without reserving a port".

from oauth2-proxy.

Correct, same same, but different :) Easier to userspace that PrivateNetwork for random processes also, but no iptables capability.

I have been playing about with PrivateIPC in systemd, but it's very bothersome to use when you have this scenario.

It should be noted that the systemd-proxyd way actually solves it by having root forward the packets instead. With the extra layer of a service that is though. That way neither nginx nor oauth2-proxy have any elevated privileges.

from oauth2-proxy.