tech-security archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
inetd(8): security behavior
I have sent another message, about inetd, to tech-userlevel for a more
limited scope (correction of bugs about not handling realpath(3) return
status) but there are more problems, IMHO, from a security standpoint in
inetd (the current status; I seem to remember that there was a proposal
to change the configuration processing; is this the result?).
The security question: config() doesn't return a status (so caller
has no information about errors) and merges any directive until it
perhaps choke on an error, but not undoing all the directives coming
from a faulty config file and neither exiting on error.
I'm a bit unconfortable about this behavior: is this possible
that someone starts by allowing things globally and then, lately,
in the file, disable some particular points, and the disabling is
never made because the parsing choked on a previous line?
What do you think?
--
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
Home |
Main Index |
Thread Index |
Old Index