[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] OpenRC supporting systemd units
From:       Michael Mol <mikemol () gmail ! com>
Date:       2013-05-08 20:22:51
Message-ID: 518AB41B.3020607 () gmail ! com
[Download RAW message or body]


On 05/08/2013 04:06 PM, Chí-Thanh Christopher Nguyễn 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.
> 
> You could be looking at someone trying to compromise your system through a
> buffer overflow or similar vulnerability. If you enable automatic respawn
> then congratulations, you just gave the attacker unlimited tries to guess
> 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.



["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]