apologies for butting-in without being able to continue the thread, but i've just seen this: http://advogato.org/person/etbe/diary/779.html which links to this: http://lists.debian.org/debian-devel/2010/05/msg00067.html
can i please gently remind people that depinit solved the security and fork-bombing issues years ago. i do keep mentioning depinit, on debian lists, but there is typically absolutely zero response, which i do not understand. nevertheless, as a debian and free software advocate i feel compelled to keep pointing people at solutions: it's up to you to investigate them. depinit solved the fork-bombing issue because richard lightman was concerned about attacks on his internet-facing system. richard added code which actively tracks child signals (depinit is highly unusual and innovative in that it catches ALL signals, and can therefore react _to_ any signal) and analyses the timing etc. and provides a means to trigger arbitrary "scripts" based on the signal type. i recall a discussion with richard back in 2004/5 where he said that when depinit is asked to stop a dependency/service, it does so by first sending "graceful" signals, then goes on to take increasingly aggressive action, including deciding, based on child-fork-bombing, that a service has been corrupted and thus needs to be terminated with extreme prejudice. richard also solved the security PID problem ... by doing away with the need for the PID file. in other words, a service is _always_ run in "foreground" mode. if it dies (i.e. a segfault signal is caught), the service is restarted automatically - by depinit (based on the signal alone). thus, the need for safe_mysql goes away entirely; the need for "apache2ctl start" goes away (i.e. you use apache2 -c FOREGROUND=True or whatever it is) and so on. in this way, there simply _is_ no need for a PID file, period. the relevant state information is contained within depinit itself, and you can guarantee that depinit will catch the signal. one additional incredibly useful action of this "foregrounding" approach to services was that he added the means to connect dependent services via pipes, between their stdin and stdout. the advantage of the entire services approach that richard took in depinit is phenomenal: richard created dependent services where in real-time you could script sshd's stdout (logging output) into _another_ service, which was a shell-script that analysed the contents and looked for "unauthorised login" attempts. more than three of those occurring within a specified time, and iptables would be called to block that user's IP address. voila: no delays due to syslog polling: instant and real-time attacker blocking, all using simple shell scripts. [the alternative - continuous polling and reading of syslog entries - is just utterly messy, results in potential delays, and requires that each and every "polling" program written for a particular service understand the concept of syslog, how to read it, how to read the last entries etc. etc. just... messy.] so i feel compelled to point these things out, along with the other incredible benefits that depinit brings including _massive_ reductions in startup time (25 seconds on a 1.5ghz Pentium 4 when debian was doing about 90 at the time), and phenomenal near-unbelievable improvements in shutdown time (2 seconds on a 1.5ghz Pentium 4 when debian was doing about 60 at the time), as it pains me to see depinit being totally ignored and these security and painful issues being discussed _years_ after a solution has already been done, and proven to be effective. you are welcome to contact me and discuss this further, if i can remember any of the details i will be glad to describe them, and if necessary go dig out the depinit scripts that i created for a KDE debian desktop system, 4 years ago. which included solving the udevsettle massive delay problems, by parallelising them and working out the dependencies for critical startup services. l. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimphzloqs1kfvzin2_er_z2qffhihhvnpq36...@mail.gmail.com
