[squid-dev] [RFC] on_crash

[Amos Jeffries]

On 10/12/2015 10:17 a.m., Alex Rousskov wrote:
> On 12/09/2015 01:43 PM, Amos Jeffries wrote:
> 
>> I am not going to +1 this right now, because the issues below are
>> security related. I would like to see at least one round of audit with
>> them resolved before it goes in.
> 
> This was not a [PATCH], only an [RFC]. The problems you are referring to
> are just artefacts of the current temporary code. I will address the one
> problem that was not:
> 

Ack. Just thought you should know the considerations to help smooth
future submissions while I had time to do it.

> 
>> * function should be "static void" it seems.
> 
> It should not IMO: It is very convenient to call this function from
> other code places when triaging something (without crashing Squid), even
> though the shipped code may not call it from anywhere else. The function
> should be designed so that it can be called from nearly anywhere.
> 
> For example, I was calling this function after every mlock(2) to see how
> shared memory statistics changes...

Then its missing the src/fatal.h chunk.

> 
>> For anyone thinking of bundling a helper for this please make the
>> reporter a binary. For the same reasons quoted above regarding system()
>> and environment contents. Also avoiding the speed (and memory) overheads
>> of bash/cash/ksh/python/php/whatever is a very good idea in these
>> situations.
> 
> A binary is great if you know exactly what you need and can easily get
> that using C/C++.
> 
> For triaging issues, a script usually works much better, especially when
> you are the one shipping the script, and the admin is the one
> tuning/adjusting it based on the information collected by the script.
> This use case was the motivation for the posted hack.
> 
> Different use cases benefit from different approaches [and have
> different security postures]. Squid itself should be strict enough to
> accommodate all major use cases, of course, but the handlers may vary
> from a basic insecure shell script to an ISO-certified secure assembly
> code :-).


Yes. I am not objecting to a script being used or configurable. Just
that if we *bundle* a helper it should not have that flaw. The above
considerations are all good reasons for us not to be bundling by default
IMO.

Amos