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. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
