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
not?
> names that don't end in ".conf" (or ".inetd" or whatever you think
> the proper suffix should be),
Yes.
> 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 man.netbsd.org'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)
10.10.10.10:
.include "private-stuff/"
20.20.20.20:
.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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index