Re: inetd(8): continue or exit on error?

[tlaronde%polynum.com@localhost]

Le Mon, May 29, 2023 at 07:49:44AM -0400, Mouse a écrit :
> >> I'm not sure inetd(8) has any business calling realpath in the first
> >> place.
> 
> I agree.
> 
> > It has to call realpath(3) since in order to not include several
> > times the same file, it makes strings comparaisons about names.
> 
> If I as an admin write a config that tries to include the same file
> twice, whether via the same or different paths, I expect it to include
> the same file twice.  If that leads to errors, that's on me.  (It might
> or might not _always_ lead to an error, depending on how the include
> file syntax is defined to interact with the stateful aspects of the
> config language and what's in the config files.)

I tend to agree that since, with globbing, the order of the inclusion of
files is not guaranteed, reloading several times the same file, as long
as there is no loop, is not less legitimate (but for
globbing, there could be an added defined behavior to sort
lexicographically the files list so that carefully choosen names can
guarantee a defined order of inclusion; and this will be compatible with
"present" behavior, since no order was guaranteed; hence any order
imposed now will do). 

But, at first, I will add a flag to check the present syntax and keep 
the present theorical behavior (in fact, due to bugs, it doesn't
work), and will correct the bugs and make the program exit on error.

And only in a second time, perhaps review the way things are processed
(perhaps allowing multiple inclusions of the same file---do what
the admin requested; as you wrote, it is his work so his responsability
as long as, syntactically, the program can parse what he asked, deliver).

> If you really want to avoid including the same file twice even if
> that's what the config says to do, I'd say it should do so with
> dev/ino > comparisons, not pathname comparisons.

Yes. Since the operation of calling realpath then open is definitively
not atomic, hence the success of realpath(3) been no guarantee of the
opening of the file, and since realpath has to go in kernel space also,
so there is no process time gained, even if I maintain the not multiple
inclusions for the first step, I will make the comparisons with lower
level identifiers. 
-- 
        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