Chris's Wiki :: blog/web/ReverseProxiesForFilePermissions Commentshttps://utcc.utoronto.ca/~cks/space/blog/web/ReverseProxiesForFilePermissions?atomcommentsDWiki2023-03-09T05:20:49ZRecent comments in Chris's Wiki :: blog/web/ReverseProxiesForFilePermissions.By Aristotle Pagaltzis on /blog/web/ReverseProxiesForFilePermissionstag:CSpace:blog/web/ReverseProxiesForFilePermissions:810c55a519df0599bfebec99af7624c1312a8a39Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>(On second thought, I misidentified the extra cost of the socket solution. It’s not the separate UID per sub-server (that is of course necessary anyway) but the extra group needed so that each sub-server UID and the Apache UID can share a group that nobody else is in.)</p>
</div>2023-03-09T05:20:49ZBy Aristotle Pagaltzis on /blog/web/ReverseProxiesForFilePermissionstag:CSpace:blog/web/ReverseProxiesForFilePermissions:353b8286203973cfd1b01b44781d4d5d9ad79c75Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>Making that work requires each sub-server to run under a separate UID, so it can be a member of a group with access to the files and a member of a group that also contains Apache’s UID, so that Apache can have sufficient permission to read the socket.</p>
<p>Doing it via a TCP socket requires more filtering, but avoids the UID-per-subserver situation.</p>
<p>Either way the use of sub-servers means trading the steadily expanding set of privileges for the Apache UID for a steadily expanding set of running processes hanging around in case Apache needs to talk to them.</p>
<p>I was going to wonder whether <code>xinetd</code> or something of the sort would be a realistic solution for that. But then I realized that <code>xinetd</code> would have to spawn each sub-server under a different UID, so this would just shift the superset of privileges to <code>xinetd</code>, and at that point I have to wonder if there isn’t some suexec-type model that would achieve the same thing without redundant moving parts.</p>
<p>So far none of these approaches sounds convincingly like a good solution to me…</p>
</div>2023-03-08T19:46:33ZBy Nico on /blog/web/ReverseProxiesForFilePermissionstag:CSpace:blog/web/ReverseProxiesForFilePermissions:9bed5a265ebd9a79566ce30ae009aacd5bee931bNico<div class="wikitext"><p>You could do reverse proxy over an Unix socket, that remove the complexity of filtering localhost.</p>
<p>Nginx support listening on Unix socket & apache' mod_proxy can use it.</p>
</div>2023-03-08T17:04:34ZBy Tom on /blog/web/ReverseProxiesForFilePermissionstag:CSpace:blog/web/ReverseProxiesForFilePermissions:58dd73ed71e0d582e6707f50bd226ee7c67098a1Tom<div class="wikitext"><p>I'm guessing the two user groups are so that the main server can access the sub-server sockets and nothing else can. In which case, I thought could avoid that by using systemd provided sockets for the sub-servers. They can be made accessible to the main server and <em>not</em> the subservers, the later of which will access them via already opened FD.</p>
</div>2023-02-20T21:46:40Z