Re: Inetd Enhancements - Include Directive

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I would argue skipping hardlinks is a [mistake].  [...]
> I meant to convey that neither hard links nor symbolic links will be
> skipped.

Ah!  Then we're in furious agreement, it would appear.

>> Suggestion: provide a directive (!depthlimit?) that allows setting
>> the limit.
> This is really good suggestion, we will certainly try this.  I guess
> my only question regarding this would be what happens when an
> included file tries to change the depthlimit?  Or should the
> directive be ignored outside of the primary configuration file?

The latter is certainly one way to address the question.  In an
abstract sense (that is, independent of considerations like how
difficult it is to implement) I would say that depthlimit should affect
all inclusion happening up to the end of the file the depthlimit
directive appears in.

Thus, in

(main config)
	!depthlimit 10
	!include foo
	!include bar
(foo)
	!depthlimit 25
	!include bar
(bar)
	# Or anything else that hits the include limit
	!include bar

I would say the top-level include of bar would detect an error at depth
10 but the include of bar nested inside foo would detect an error at
depth 25.  (If that even makes sense; the first error probably would
abort the parse, in practice.)

That then raises the question: does depthlimit in an included file
apply to the total inclusion depth or the inclusion depth relative to
that file?  If the latter, then

(foo)
	!depthlimit 4
	!include foo

will recurse until it runs out of available resources (stack space,
file descriptors, whatever).  I'm not sure this is a bad thing; trying
to make it _impossible_ for admins to shoot their systems in the foot
either fails or ends up crippling something, usually something
important.  But it makes sense, to me, for files to behave the same
regardless of how deeply they're included from.

However, I'd also raise another question: why do you _want_ to have an
inclusion depth limit?  Is it just to give a better error than crashing
for lack of some relevant resource, or what?  If it's just to catch
recursive includes, then you might do better by not having any specific
limit, but instead erroring when trying to include any file
recursively.  (This assumes you have nothing like conditional flow
control that could make the file behave differently on different
inclusions.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B