Re: [squid-users] Re: Again with winbindd_privileged, sometimes "Ensure permissions on /var/db/samba/winbindd_privileged are set correctly"

From: c0re <nr1c0re_at_gmail.com>
Date: Wed, 29 Sep 2010 16:21:47 +0400

Thanks, Amos, for your reply.

I was just complaining about giving to squid user access to privileged
group "wheel" in freebsd.

If it's the only way, i'm stopping bumping this thread :)

Thanks to all for your replies!

2010/9/29 Amos Jeffries <squid3_at_treenet.co.nz>:
> On 30/09/10 00:19, c0re wrote:
>>
>> Going in depth I found in man winbindd following:
>>
>>        $LOCKDIR/winbindd_privileged/pipe
>>            The UNIX pipe over which 'privileged' clients communicate with
>> the
>>            winbindd program. For security reasons, access to some winbindd
>>            functions - like those needed by the ntlm_auth utility - is
>>            restricted. By default, only users in the 'root' group will get
>>            this access, however the administrator may change the group
>>            permissions on $LOCKDIR/winbindd_privileged to allow programs
>> like
>>            'squid' to use ntlm_auth. Note that the winbind client will
>> only
>>            attempt to connect to the winbindd daemon if both the
>>            $LOCKDIR/winbindd_privileged directory and
>>            $LOCKDIR/winbindd_privileged/pipe file are owned by root.
>>
>> And that's true. I need to change group to squid to
>> winbindd_privileged  AND winbindd_privileged/pipe.
>> Trying to figure out on to how to ask winbind to make it's pipe with
>> another group like winbind_priv... winbind makes it root:wheel by
>> default.
>
> False. The permissions situation has been explained to you twice already. It
> has not changed:
>  * You need to remove cache_effective_*group* setting from overriding the
> group permissions assigned to Squid by the OS extended-groups security
> system.
>  * You need to make the squid cache_effective_*user* a member of the OS
> group with read access to $LOCKDIR/winbindd_privileged
>
> When these two conditions are true Squid and its wbinfo helpers will have
> access to verify users and groups.
>
> Samba periodically resets the ownersip permissions on its
> $LOCKDIR/winbindd_privileged resources. This is a known problem with the
> hack workaround of changing it to "squid" group. It sounds to me like
> exactly this is happening while Squid is active and you get that log line
> entered until something else comes along and removes the Samba security
> again.
>
>
> This in no way fixes any other auth problem which may be occurring.
>
> There are secondary problems known on some older OS variants before the
> correct permissions fix was confirmed:
>
> 1) several OS (RedHat and children) hard-code the cache_effective_group to
> some value. This prevents you being able to use the OS security system
> groups the way winbind needs. The fix for this is to build your own from
> source without the config defaults patching.
>
> 2) at least one OS (Gentoo) default the group ownership of
> winbindd_privileged to "squid" and patch winbind to work with that in its
> own way.
>
> 3) SELinux can prevent Squid from accessing things that would otherwise seem
> perfectly accessible.
>
> 4) Squid has several bugs and flaws which cause it to drop credentials under
> some conditions. These are still being worked out and checked. The big
> visible sign of these is extra auth challenges. Two are open against the 3.1
> series.
>
> Amos
>
>>
>> 2010/9/3 Diego Woitasen<diegows_at_xtech.com.ar>:
>>>
>>> On Fri, Sep 3, 2010 at 8:54 AM, c0re<nr1c0re_at_gmail.com>  wrote:
>>>>
>>>> I found strange solution:
>>>> stop squid&windbind
>>>> rm -rf /var/db/samba/winbindd_privileged
>>>> start winbind
>>>> chown :squid /var/db/samba/winbindd_privileged
>>>>
>>>> And problem disappeared.
>>>>
>>>> 2010/9/1 c0re<nr1c0re_at_gmail.com>:
>>>>>
>>>>> Hello squid users!
>>>>>
>>>>> I've got squid+winbind ntlm auth.
>>>>> But sometimes I see this in log /var/log/samba/log.winbindd
>>>>>
>>>>> [2010/09/01 12:39:11,  2]
>>>>> winbindd/winbindd_pam.c:winbindd_pam_auth_crap(1754)
>>>>>   winbindd_pam_auth_crap: non-privileged access denied.  !
>>>>>   winbindd_pam_auth_crap: Ensure permissions on
>>>>> /var/db/samba/winbindd_privileged are set correctly.
>>>>>
>>>>> About 1k users.
>>>>> Sometimes some user can see proxy auth window asking for credentials in
>>>>> IE6.
>>>>> User can just press ESC and do not enter any credentials, all goes OK.
>>>>> That window means that some ntlm auth problem occurs.
>>>>> In log I see only those message above about winbindd_privileged.
>>>>>
>>>>> freebsd 7.3
>>>>> squid 3.1.7
>>>>> samba-3.3.10
>>>>>
>>>>> In squid.conf
>>>>> no cache_effective_group option configured
>>>>> auth_param ntlm program /usr/local/bin/ntlm_auth
>>>>> --helper-protocol=squid-2.5-ntlmssp
>>>>> auth_param ntlm children 150
>>>>>
>>>>> Using cachemgr.cgi and looking at "NTLM User Authenticator Stats" I
>>>>> see only 32 redirectors has changed "# Request" counters, that means
>>>>> that not all 150 redirectors used so it's not redirector problem.
>>>>>
>>>>> # ls -l /var/db/samba/ | grep winbindd_privileged
>>>>> drwxrwx---  2 root  squid     512 Aug 22 13:58 winbindd_privileged
>>>>>
>>>>> # ls -l /var/db/samba/winbindd_privileged/
>>>>> srwxrwxrwx  1 root  squid  0 Aug 22 13:58 pipe
>>>>>
>>>>> What can be wrong? If there were incorrect permissions no one can auth
>>>>> via ntlm, but all users can authorize and walk in internet. I can't
>>>>> find why sometime those auth window appears and why those message
>>>>> about "permissions" appears in log.
>>>>>
>>>>> Thanks in advance!
>>>>>
>>>>
>>>
>>> That's not the correct solution. The squid user should be member of
>>> the group winbindd_priv and you have to remove the
>>> cache_effective_group from squid.conf.
>>>
>>> Regards,
>>>  Diego
>>>
>>>
>>>
>>> --
>>> Diego Woitasen
>>> XTECH
>>>
>
>
> --
> Please be using
>  Current Stable Squid 2.7.STABLE9 or 3.1.8
>  Beta testers wanted for 3.2.0.2
>
Received on Wed Sep 29 2010 - 12:21:53 MDT

This archive was generated by hypermail 2.2.0 : Wed Sep 29 2010 - 12:00:04 MDT