Re: inetd(8): cmdif as builtin

[tlaronde%polynum.com@localhost]

Le Fri, Jun 09, 2023 at 08:47:10AM -0400, Mouse a écrit :
> > BTW; just an idea: in the case of inetd(8), wouldn't it be more
> > simple and logical, in this very case, to add a "cmdif" (cmd
> > interface) builtin?
> 
> Simpler and more logical than what?

Emphasis: in the inetd(8) context. In this context, where inetd is
designed to wait listening for sparsely used services (the case for a
command line interface); that can limit the number of connections; that
can connect to various types of interfaces; it seems not logical to
perhaps try to add code that will duplicate part of its own "raison
d'\^etre".

> 
> 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.)

Yes, of course. The scheme (in principle) is simple: inetd waits for a
connection on the given interface (as defined by a service entry in its
configuration file). When a connection occurs, it defers the
authentification to some service that, if authentification is
successful, "plumb" the external user with inetd command interpreter
(once the authentification is done, it is just a pass-through).

> 
> The biggest difference I see between this and using signals to provoke
> these actions is the target namespace: filesystem names for AF_LOCAL or
> process IDs for signals.

More than this: you can pass parameters with signals. So for a command
interface, signals are convenient if you need only a few totally defined
actions to trigger, but are not convenient if you want parameters or a
richer set of actions.

I'm still thinking (background process) about the subject you have started
in another thread (about a way to pass commands to a process in a more
broad way than what is allowed by signals).

I think it deserves more attention and deserves a solution in the system.

All in all, why daemon(3) or a variation of daemon(3) would not change stdin
and stdout to not be linked to the controlling terminal but precisely to
another interface that allows sending commands and receiving results, and
deferring error or logs via stderr? This is just "plumbing"---and Plan9 has
simply pushed the concept further; but it's already there.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C