> On Oct 22, 2016, at 17:23, K. Fossil user <ticketpersonnal-fos...@yahoo.fr> > wrote: > P.S. : I will never understand why people don't know about security issue > when it comes to inetd.
Aha, so this was a security concern. I figured just as much. Please read on. (: > I was explained to never use ONE daemon for many servers. When needed ONE > daemon for ONE server and not more. OK, so, from a systems design standpoint, inetd and xinetd don't inherently have insecure designs as super servers. Instead, that design lends them a tendency to exhibit pathological unreliability; if inetd or xinetd crash (say, because the configuration parser has a bug because it unwittingly derefs NULL), the services that are run under the auspices of either one will similarly meet a less than pleasant fate. The security concerns come in as a result of not paying attention to the details of the implementation. Make sure you use things like initgroups(3), setgid(2), and setuid(2) to drop privileges. Make sure you understand how inter-process communication can be made secure. Make sure you have good hygiene when you dynamically allocate memory and work with, e.g., NUL-terminated strings. Now, it just so happens that it's simpler to keep track of the security details in things like tcpserver and tcpsvd because the single-instance-per-single-server architecture lends itself well to fewer lines of code to serve as a liability, but that is by no means a guarantee. Caveat emptor. > 2/ Xinetd is old (four years ?) so may be not secure. xinetd is actually older than that. It may have not, for whatever reason, seen a recent release. That said, xinetd has comparatively few lines of code (granted, it's still more than tcpserver and tcpsvd for just the configuration file bits alone) when placed next to other pieces of software that often run in part with escalated privileges like, well, modern full-featured HTTP servers. Also, it's folly to discount everything above a certain age as insecure. tcpserver, part of Dan Bernstein's ucspi-tcp package, has a solid design that lends itself very well to running TCP servers that are invulnerable to the exploits you're afraid of. I don't think it has seen an update in 15 years. Anyway, that's all I have to say about that. —n _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
