Re: [squid-users] R: [squid-users] WARNING: no_suid: setuid(0): (1) Operation not permitted

On 4/02/2013 11:35 p.m., Simone Levy wrote:
> On 02/01/2013 01:09 AM, Amos Jeffries wrote:
>> On 1/02/2013 6:03 a.m., Alex Rousskov wrote:
>>> On 01/31/2013 03:06 AM, Amos Jeffries wrote:
>>>> On 31/01/2013 10:24 p.m., Simone Levy wrote:
>>>>> Hello there,
>>>>>
>>>>> we are receiving warnings after upgrading squid from version 3.1 to
>>>>> 3.2 on FreeBSD. Squid appears to be fully operational though.
>>>>>
>>>>> The warnings seem to be relative to starting the helpers and opening
>>>>> the log files, but the helpers are started and the log files written to.
>>>> When dealing with logs from asynchronous event code things are not
>>>> always as they seem.
>>>> If those are working its most likely not them.
>>>>
>>>> You might have to start Squid under a debugger to find out what
>>>> specifically setuid is being called for.
>>> Amos,
>>>
>>> FWIW, I have seen this warning on FreeBSD as well. Squid calls
>>> set_uid(0) unconditionally. My setuid man page does not mention UID of
>>> zero, and I have not investigated why that call was added, but I have a
>>> feeling that FreeBSD does not like it:
>>>
>>>> no_suid(void)
>>>> {
>>> ...
>>>> debugs(21, 3, "no_suid: PID " << getpid() << " giving up root priveleges for ever");
>>>>
>>>> if (setuid(0) < 0)
>>>> debugs(50, DBG_IMPORTANT, "WARNING: no_suid: setuid(0): " << xstrerror());
>>
>> Hmm. Yes the warning is new since we started adding debugs() about failed system calls to display reviously hidden system errors.
>>
>> Looking at all the documentation about setuid() and seteuid() I'm wondering if this was supposed to be seteuid(0) - to clear any effective-user restrictions before dropping
>> privileges down to the low-privileges UID.
>>
>> I'm also wondering if setuid(uid) was done earlier and the low-privilege user is what is being dened the setuid(0) - but I can't see any sign of the "Dropping privileges"
>> message that should appear first. Can one of you start your Squid with level-3 debug and see where in this startup list the dropping message appears?
>>
>> There is also http://bugs.squid-cache.org/show_bug.cgi?id=3751 involved with this somehow.
>>
>>
>> Amos
> Hi Amos,
>
> here's a cache.log excerpt after setting debug_options ALL,3.
>
> 2013/02/04 09:44:35.142| tools.cc(757) enter_suid: enter_suid: PID 2156 taking root privileges
> 2013/02/04 09:44:35.142| cache_manager.cc(103) registerProfile: registering legacy config
> 2013/02/04 09:44:35.142| cache_manager.cc(88) registerProfile: registered profile: config
> 2013/02/04 09:44:35.142| mem.cc(485) Report: Memory pools are 'on'; limit: 5.000 MB
> 2013/02/04 09:44:35.142| main.cc(1414) SquidMain: Doing post-config initialization
>
> 2013/02/04 09:44:35.142| tools.cc(690) leave_suid: leave_suid: PID 2156 called
> 2013/02/04 09:44:35.142| tools.cc(712) leave_suid: leave_suid: PID 2156 giving up root, becoming 'squid'
> 2013/02/04 09:44:35.142| tools.cc(757) enter_suid: enter_suid: PID 2156 taking root privileges
> 2013/02/04 09:44:35.143| fd.cc(221) fd_open: fd_open() FD 0 stdin
> 2013/02/04 09:44:35.143| fd.cc(221) fd_open: fd_open() FD 1 stdout
> 2013/02/04 09:44:35.143| fd.cc(221) fd_open: fd_open() FD 2 stderr
> 2013/02/04 09:44:35.143| tools.cc(690) leave_suid: leave_suid: PID 2156 called
> 2013/02/04 09:44:35.143| tools.cc(712) leave_suid: leave_suid: PID 2156 giving up root, becoming 'squid'
> 2013/02/04 09:44:35.143| fd.cc(221) fd_open: fd_open() FD 3 /var/log/squid/cache.log
> 2013/02/04 09:44:35.143| Starting Squid Cache version 3.2.6 for amd64-portbld-freebsd9.0...
> 2013/02/04 09:44:35.143| Process ID 2156
> 2013/02/04 09:44:35.143| Process Roles: master worker
[...]
> 2013/02/04 09:44:35.144| helperOpenServers: Starting 5/20 'ntlm_auth' processes
> 2013/02/04 09:44:35.144| fd.cc(221) fd_open: fd_open() FD 7 IPC UNIX STREAM Parent
> 2013/02/04 09:44:35.144| fd.cc(221) fd_open: fd_open() FD 8 IPC UNIX STREAM Parent
> 2013/02/04 09:44:35.144| ipc.cc(196) ipcCreate: ipcCreate: prfd FD 7
> 2013/02/04 09:44:35.144| ipc.cc(197) ipcCreate: ipcCreate: pwfd FD 7
> 2013/02/04 09:44:35.144| ipc.cc(198) ipcCreate: ipcCreate: crfd FD 8
> 2013/02/04 09:44:35.144| ipc.cc(199) ipcCreate: ipcCreate: cwfd FD 8
> 2013/02/04 09:44:35.144| comm.cc(1077) _comm_close: comm_close: start closing FD 8
> 2013/02/04 09:44:35.144| comm.cc(735) commUnsetFdTimeout: Remove timeout for FD 8
> 2013/02/04 09:44:35.145| tools.cc(690) leave_suid: leave_suid: PID 2157 called
> 2013/02/04 09:44:35.145| tools.cc(783) no_suid: no_suid: PID 2157 giving up root priveleges forever
> 2013/02/04 09:44:35.145| WARNING: no_suid: setuid(0): (1) Operation not permitted
> 2013/02/04 09:44:35.145| comm.cc(735) commUnsetFdTimeout: Remove timeout for FD 7

Like I thought it is running no_suid() while at the low-privileged
account level.

You are also right, it is the forked helper process which is doing the
no_suid().

Amos
Received on Mon Feb 04 2013 - 11:39:32 MST