Hallo there,
should this issue be reported as a bug or otherwise dealt with?
Thanks,
Simone
On 02/04/2013 12:39 pm, Amos Jeffries wrote:
> 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
________________________
Simone Levy
+39.02.581913.59
simone.levy@xxxxxxxxxxx
Trebi Generalconsult srl
