On 23-06-13 07:45, Brett Lymn wrote: | On Fri, Jun 09, 2023 at 08:47:10AM -0400, Mouse wrote: | > | > In any case, the major issue I would have with it is the lack of | > authentication. But that's so obvious that I assume you would be doing | > something like requiring a password - or doing it only for AF_LOCAL | > sockets and using LOCAL_PEEREID. (This is pretty close to what most of | > my pidconn servers do - they use the pidconn analog of LOCAL_PEEREID to | > verify that the client is either root or the same UID the server is | > running as.) | > | | When this was done in last years GSoC it was a AF_LOCAL socket to | control inetd. I am not sure that inetd having a configuration service | listening on the network is a really good idea - to me, it sounds | dangerous and I am dubious that there are many situations that require | remote configuration of inetd.
I agree. If you keep it to AF_UNIX, then you can enforce LOCAL_PEEREID (or SO_PEERCRED or equivalent) checking to ensure that the peer is an appropriate local UID (or GID). You could even have different tiers of control, such as "group X for query status" (e.g., for remote monitoring apps that connect in via SSH or whatever), versus "group Y for admin privs to change status", although that's scope creeping... This reduces the remote attack surface to your operations and management (OAM) / MANO / ... systems. If you need "remote" management, solve it like we do for a lot of other systems and remote in (i.e, ssh) to run as a local user, with the existing remote access controls for that.
