[squid-dev] [RFC] on_crash

[Alex Rousskov]

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:


> * 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...


> 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 :-).


Thank you,

Alex.