Perhaps we're peculiar, but one of the challenges we keep running into over and over again in our web servers is that someone wants to expose access-restricted Unix files to selected local people via the web, rather than making people log in and slog through the filesystem. The actual access restrictions are not a problem because we have a well developed system using HTTP Basic Authentication (and someday it will be extended to be a single sign on environment). However this still leaves us with the challenge of giving the web server the permission to read those files. Our traditional approach has been group membership, which has created several Apache UIDs that have a steadily expanding set of privileges.

Today, in a blinding flash of the obvious, I realized that an alternate approach to solving this problem is reverse proxies. For each set of files with Unix access restrictions, we can use or set up a login that specifically has access to them, then have that login run a simple web server that serves those files. Then the main web server reverse proxies to all of those sub-servers, with appropriate HTTP Basic Authentication or other access controls in front. Each sub-server has strictly limited access to its own files, and the main Apache server doesn't need to have access to anything (beyond the ability to talk to the sub-servers). Much as with our regular user-run web servers, a sub-server could run potentially dangerous things like PHP without endangering anyone else.

(We wouldn't want these sub-servers to be regular user-run web servers, because there's no internal access controls on who can talk to user-run web servers. You would definitely want access to the sub-servers to be limited to the main Apache.)

There are a number of plausible approaches to making sure that only the main Apache can talk to the sub-servers. Since one concern is potential cross-compromise (especially with PHP in the mix), we'd definitely want to get this right. For localhost traffic, Linux iptables can restrict things by the UID that generated the packet, or we might be able to reverse proxy over Unix domain sockets (although things are tricky there unless we want a lot of two-login groups). If the frontend Apache is on a different machine, we can restrict inbound network traffic to the sub-servers to be from that machine (and then restrict who can do outbound traffic on that machine, if we allow any access to it at all).

We might not want to use Apache for most of these sub-servers, since all they need to do is serve files and Apache is still fairly heavy-weight for that. Something with a simple configuration and operation would probably be ideal for most cases. On the other hand, Apache is right there and we know how to set it up and operate it.

(What triggered this flash of the obvious was this Fediverse post by @anarcat.)