tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inetd enhancements - config syntax

> ...and also, for your own and the operator's sanity, skip anything
> else beginning with '.',

Not sure I agree with that; I'd have to think about it.  I could argue
it either way.  Why do you think .-prefixed entries should be skipped?

Relatedly, do you feel the same way about names beginning with, or
containing, other unusual things, such as , + | ~ # * % !?  Why or why

> names that don't end in ".conf" (or ".inetd" or whatever you think
> the proper suffix should be),


> and anything that isn't a regular file (DT_REG).

I don't recall whether this is relevant (it's been quite a while since
I did anything with d_type), but I strongly believe that symlinks
should be followed before any such test.

> (If you get DT_UNKNOWN it's reasonable to call stat to get the real
> type rather than just skipping it, and you might want to allow
> symlinks, but definitely skip directories, devices, named pipes,
> etc.)

I'm not sure I agree.  (I'm also not sure I disagree.)  I certainly
don't have any immediate use for any such, but I'm also very unsure
this wouldn't be a case of forbidding stupid things and thereby
forbidding clever things.  Maybe a switch to turn it off, or maybe
people who want to get that clever should just hack on the source
themselves?  I'm not sure how reasonable I think that is.

If such a check does go in, well, I don't *think* O_PLAIN (fail if the
putatively-opened object isn't a plain file) dates back far enough I
got it into NetBSD's tree, but if there isn't currently anything
equivalent, maybe it'd be worth adding?  I found it borderline trivial
to add, and it really helps for things like this.  I should probably go
read's open(2)....

> ...also I strongly recommend against having global settings that are
> meant to change around as things are included (such that the order
> includes are processed in matters) -- you wouldn't write code that
> used global variables that way, don't do it in configs...

I may - occasionally - write code that uses global variables that way,
depending on precisely what you mean.  I definitely think there is a
place for (to borrow from the current syntax for a moment)
.include "private-stuff/"
.include "world-facing-stuff/"
.include "everybody-stuff/"

This may or may not be an example of what you're talking about.

I do think the order in which the directory entries appear in the
directory should not matter; either the spec should be such that the
order in which they're processed doesn't end up mattering, or the
entries should be sorted in a well-defined order (whether hardwired or
chosen by the admin or indicated by the include directive or what).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Home | Main Index | Thread Index | Old Index