summaryrefslogtreecommitdiff
path: root/swat
diff options
context:
space:
mode:
authorGerald Carter <jerry@samba.org>2007-05-30 19:47:35 +0000
committerGerald (Jerry) Carter <jerry@samba.org>2007-10-10 12:22:58 -0500
commit9b78af1f64015ae63948de565754ad8f6af66cbe (patch)
tree0ba73b84f5118a3991433c23ca6983fc18d42b75 /swat
parent4eab22b8938dfe846f7a12002c8ff8ae158acecd (diff)
downloadsamba-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 'swat')
0 files changed, 0 insertions, 0 deletions