On 23/05/2013 4:29 a.m., Alex Rousskov wrote:
On 05/22/2013 09:25 AM, Eliezer Croitoru wrote:
On 5/22/2013 5:59 PM, Alex Rousskov wrote:
On 05/22/2013 07:00 AM, Amos Jeffries wrote:
I had the idea that we could add a new Kid type of "Helper" and
differentiate the spawned helper processes with it:
http://master.squid-cache.org/~amosjeffries/patches/FreeBSD_silence_nosuid_mk1.patch
Identifying helper kids is a good idea in general, but I would very much
prefer that we at least understand what the true problem is here before
we mask it away. Your second January 31, 2013 email on squid-users is a
good summary of what needs to be investigated. Please do not suppress
the warning until we know why it happens and are certain that hiding it
is the best way forward.
Agreed. I have applied the helper identifying change to trunk
(rev.12854) so we can use it in debugs or whatever.
But have omitted the part in tools.cc until the answers to those
questions are all known...
I am +1 to understand a bit the source for the problem
Do you have any approach or direction to what can lead to it?
If you want to work on it, I recommend starting by finding answers to
the following questions:
1a. What exactly does setuid(0) do on Linux?
1b. What exactly does setuid(0) do on FreeBSD?
2a. Do we need that call where it is now? Why?
As far as I was able to determine, Squid drops *most* but not all of its
root privileges. It holds on to just enough privilege to perform
enter_suid() as needed. This no_suid() is about dropping that last
remainder privilege entirely from the even-more security critical processes.
Which hints at the Linux/FreeBSD difference: Linux treats a useless
drop (privilege already gone) as a success. FreeBSD treats it as a
failure for some reason, which I guess is related to the drop requiring
some privilege change to happen (that guess NEEDS checking).
2b. Did the authors mean seteuid(0) instead?
No seteuid(0) has already been done.
The answers found for this question may be related to
http://bugs.squid-cache.org/show_bug.cgi?id=3751.
Amos
