Re: WARNING: no_suid: setuid(0): (1) Operation not permitted

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Sun, 26 May 2013 16:14:01 +1200

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
Received on Sun May 26 2013 - 04:14:19 MDT

This archive was generated by hypermail 2.2.0 : Sun May 26 2013 - 12:00:11 MDT