Re: [CODE] inetd FINAL

[tlaronde%polynum.com@localhost]

Le Mon, Jul 03, 2023 at 08:23:13PM +0100, David Brownlee a écrit :
> Some random thoughts :)
> 
> - Would it make sense to actively reject -l or similar when -c is given

I don't think so. They can be a "slip of the thumb" when passing
switches and they do no harm---the problem is that the checking is not
purely lexicographical and syntaxical; there is a bit of semantics
involved too: if the protocols are supported or not etc. and a user may
be a little hesitant about the switches and could think that to validate
a config to be served, the safer way is to call the program with exactly
the same options as for the server, except requesting only the checking.

Not illogical.

So I think these should be ignored---allowing rc(8) to in fact simply
prefix or postfix inetd_flags with " -c " in order to validate a config.

> - Resilient mode would probably benefit from a new {sub ,}section
> heading in the man page

Probably. And it needs a bit of rework too to make it perfectly clear
(difference between startup, when fallback can be taken if problem, and
later, when fallback is not read unless specifically requested with
USR1 signal).

> - I'd be inclined to reject a config which tries to embed a null with
> \000 or similar with an error

I think too that such an interpreted escape (passing literally the
string '\000' is not a problem) is obviously whether an error or a very
convoluted way to say that the value is the empty string---I forgot to
add that "keyword = [,;\n]" is a valid way of saying value == "" in the
man page (simply because it was allowed in the previous implementation).

Since when spawning, every argument is passed as a C string, such an
embedded null char can only truncate a string, so I don't see how it
could have any legitimate usage---except, as explained above, as a
convoluted way of saying that the value is the empty string; but, in
some sense, it is knowing too much about the implementation: the config
is user level strings and an empty string is whether nothing between
equal and separator or terminator; or '' or ""; the way, internally,
strings are handled should not be the concern of the user.

Is someone seeing a possible legitimate use of this?

If not, yes, I think too that it should be an error.

There is one more area that needs discussion: compatibility.

My implementation is compatible except for one thing: previous
implementation treated quoting between single quotes the same as quoting
between double quotes; in my implementation, it works like with sh(1):
between single quotes, no interpretation at all---and one can not put
an escaped single quote between single quotes.

And for other compatibility features but deprecated syntax: I would be
inclined to treat the deprecated features:

listen-address:

(for specifying the default host; but this causes problems if there are
spurious blanks as I will explain in the ChangeLog. This is replaced
by:

.defhost [value]
)

and:

#@ [ipsec_policy...]

(abusing a comment. Replaced by:

.ipsec [value...]
)

I would be inclined to treat deprecated features as faults in checking,
and only warnings in running during one release (in order for present
configurations to still work, when upgrading, but warning the
administrator that the period of grace will be limited).

And drop the compatibility the following release (deprecated features
then error even when serving).
-- 
        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