From gentoo-dev Wed May 08 20:22:51 2013 From: Michael Mol Date: Wed, 08 May 2013 20:22:51 +0000 To: gentoo-dev Subject: Re: [gentoo-dev] OpenRC supporting systemd units Message-Id: <518AB41B.3020607 () gmail ! com> X-MARC-Message: https://marc.info/?l=gentoo-dev&m=136804458220250 MIME-Version: 1 Content-Type: multipart/mixed; boundary="------enig2ATWFXWAGTKGBNPJEGIDI" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2ATWFXWAGTKGBNPJEGIDI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/08/2013 04:06 PM, Ch=C3=AD-Thanh Christopher Nguy=E1=BB=85n wrote: > Michael Mol schrieb: >>> Sounds like a great feature. A crashed process is a buggy one, and I = >>> would want to investigate said program before I relaunched it, and >>> not have it automatically relaunched as if nothing had happened. >> >> That's highly, highly, highly use-case dependent. If it's a >> non-critical service, or in a non-critical environment, that's one >> thing. If it's a service whose downtime can be measured in value lost,= >> that's quite another. >=20 > You could be looking at someone trying to compromise your system throug= h a > buffer overflow or similar vulnerability. If you enable automatic respa= wn > then congratulations, you just gave the attacker unlimited tries to gue= ss > the correct address/offset for his exploit. Without respawn, you're already bending over and taking a DoS. And when you're in a situation where service uptime is a cap on revenue, uptime is pretty darn important. That's not to say analyzing the crash isn't important, but if I allowed a prod service to remain down while I investigated a crash, studied the problem, evaluated a fix for correctness and lack of regressions, scrubbed the fix and tried again, I wouldn't have that job for very long!= Certainly there are environments where it's sensible to take things slow while you investigate (OpenVPN crashed? ssh crashed?), but there are environments where that's not the case, too. It depends on your threat model and a variety of cost/analysis factors. That's why I said "highly, highly, highly use-case dependent." If upstream provides a unit file, and that unit file specifies a behavior, you should (by default) trust the upstream. If you don't like what upstream does, convince them to change. If they won't, make your changes locally. If it's _really_ bad, obviously you have an interesting position as a dev in a distribution, and you might make your change there, but that certainly shouldn't be your default course of action. ------enig2ATWFXWAGTKGBNPJEGIDI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRirQeAAoJED5TcEBdxYwQngQIAJj4ojE12oyl2ELsJhIkiZ0j BY68OikhKMD+PS/7nyIJsbHjPyGxkyktq03U0sE/XDYLg3+U2KEj4KVN+9QH8T6K IGrSkLVpH74XIaamTHdKOHCd6VaL3UbB8qzeYn8eiM4FZBdGlBeCnNtNE7cqjwS4 2FyJVVBGI9Dw6zIUrzaud06PWyGFRreK0MIAsCIRLWJHnLKTP1XsEIOOIeKoDNMH 8bjPjBwCc0gTIUuX9L8GwKpLXKWgx7Qpn+WaynbLPeMTJ0oKejUkFh3PeWavvyrf ZK6mb7dUfPRF/MrTmfErkp3jPbtWoskjlh74YFVNegaKEGiEC+0V8+LpQNn1m8k= =xcq8 -----END PGP SIGNATURE----- ------enig2ATWFXWAGTKGBNPJEGIDI--