diff options
author | Gerald Carter <jerry@samba.org> | 2007-05-30 19:47:35 +0000 |
---|---|---|
committer | Gerald (Jerry) Carter <jerry@samba.org> | 2007-10-10 12:22:58 -0500 |
commit | 9b78af1f64015ae63948de565754ad8f6af66cbe (patch) | |
tree | 0ba73b84f5118a3991433c23ca6983fc18d42b75 /source3/stf | |
parent | 4eab22b8938dfe846f7a12002c8ff8ae158acecd (diff) | |
download | samba-9b78af1f64015ae63948de565754ad8f6af66cbe.tar.gz samba-9b78af1f64015ae63948de565754ad8f6af66cbe.tar.bz2 samba-9b78af1f64015ae63948de565754ad8f6af66cbe.zip |
r23244: Fix loop with nscd and NSS recusive calls.
> Here's the problem I hit:
>
> getgrnam("foo") -> nscd -> NSS -> winbindd ->
> winbindd_passdb.c:nam_to_sid() -> lookup_global_sam_name() ->
> getgrnam("foo") -> nscd -> ....
>
> This is in the SAMBA_3_0 specifically but in theory could happen
> SAMBA_3_0_25 (or 26) for an unknown group.
>
> The attached patch passes down enough state for the
> name_to_sid() call to be able to determine the originating
> winbindd cmd that came into the parent. So we can avoid
> making more NSS calls if the original call came in trough NSS
> so we don't deadlock ? But you should still service
> lookupname() calls which are needed for example when
> doing the token access checks for a "valid groups" from
> smb.conf.
>
> I've got this in testing now. The problem has shown up with the
> DsProvider on OS X and with nscd on SOlaris and Linux.
(This used to be commit bcc8a3290aaa0d2620e9d391ffbbf65541f6d742)
Diffstat (limited to 'source3/stf')
0 files changed, 0 insertions, 0 deletions