Bug 6068 - Winbind crashes after LDAP request
Summary: Winbind crashes after LDAP request
Status: RESOLVED WONTFIX
Alias: None
Product: Samba 3.2
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.2.7
Hardware: x64 Linux
: P3 critical
Target Milestone: ---
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-27 07:47 UTC by Martin Welk
Modified: 2009-02-11 12:08 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Welk 2009-01-27 07:47:20 UTC
We have a Samba 3.2.7 file server that is member of a Samba domain and uses an LDAP based id map back-end. The winbindd of this server crashed repeatingly when requesting data for some particular user accounts from LDAP. 

For each Samba user we created a single file (test-<userid>) and set ownership of that file to <userid> (we use standard POSIX ownership, no ACLs).
In the Windows file explorer, we open that share, view it in detailed view (one line per file) and add the column owner.
What we expect to see is something like "test-xxxxx   <size> <timestamp> XXXXXXXXX\xxxxx".
That directory contains about 700 files.

We show the files on an XP member workstation, with the explorer, list view, with owner tab. We see the list of files instantly, and we see the owners column filling quickly.
But for some of the owners,we only see an entry "S-1-0-0".
We have been able to track down that winbind dies with a panic when it tries to look up the idmap entry in LDAP for these users.

We have the same error using Samba 3.0.28. Our DCs and other servers are still on 3.0.20 and it works all fine there. 

This is an example of one affected user, we have a couple (probably 50).

We picked a few of these and verified them carefully:

- the user information is visible
- the users can be mapped into a SID
- the users' SIDS can be mapped into a uidnumber
- the uidnumbers can be mapped into SIDs

...all using the wbinfo command - on the command line, everything looks fine,we can't see winbind panics when we use the wbinfo command.

We've verified that our idmap backend is consistent:
- all users and groups have an idmap entry
- all used id numbers are unique

In the following, we have an example of such a panic. It seems like winbind tries gather the idmap for the sambaSID of the affected users and dies on the reply of LDAP:

=> acl_mask: access to entry "sambaSID=S-1-5-21-101473267-2020957187-6498272-41118,ou=Idmap,dc=xxxxxx,dc=xxx", attr "uidNumber" requested
=> acl_mask: to value by "", (=n)
<= check a_dn_pat: *
<= acl_mask: [1] applying read(=rscx) (stop)
<= acl_mask: [1] mask: read(=rscx)
=> access_allowed: read access granted by read(=rscx)
<= send_search_entry
send_ldap_result: conn=148 op=2 p=3
send_ldap_result: err=0 matched="" text=""
send_ldap_response: msgid=3 tag=101 err=0
[2009/01/21 19:42:46,  0] lib/fault.c:fault_report(40)
  ===============================================================
[2009/01/21 19:42:46,  0] lib/fault.c:fault_report(41)
  INTERNAL ERROR: Signal 6 in pid 2692 (3.2.7)
  Please read the Trouble-Shooting section of the Samba3-HOWTO
[2009/01/21 19:42:46,  0] lib/fault.c:fault_report(43)
Jan 21 19:42:46 xxxxxxxx winbindd[2692]:
  From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2009/01/21 19:42:46,  0] lib/fault.c:fault_report(44)
  ===============================================================
[2009/01/21 19:42:46,  0] lib/util.c:smb_panic(1663)
  PANIC (pid 2692): internal error
[2009/01/21 19:42:46,  0] lib/util.c:log_stack_trace(1767)
  BACKTRACE: 28 stack frames:
   #0 /usr/sbin/winbindd(log_stack_trace+0x26) [0x814c253]
   #1 /usr/sbin/winbindd(smb_panic+0x7f) [0x814c0dd]
   #2 /usr/sbin/winbindd [0x8138269]
   #3 /usr/sbin/winbindd [0x8138277]
   #4 [0xffffe420]
   #5 /lib/tls/libc.so.6(abort+0x1a5) [0x401ffe65]
   #6 /lib/tls/libc.so.6(__assert_fail+0x103) [0x401f7c03]
   #7 /usr/lib/libldap.so.199(ldap_next_entry+0x72) [0x40195f02]
   #8 /usr/sbin/winbindd [0x834db9f]
   #9 /usr/sbin/winbindd [0x834826f]
   #10 /usr/sbin/winbindd(idmap_unixids_to_sids+0x3b1) [0x8348dc5]
   #11 /usr/sbin/winbindd(idmap_uid_to_sid+0xa1) [0x834abdd]
   #12 /usr/sbin/winbindd(winbindd_dual_uid2sid+0x90) [0x80d1b08]
   #13 /usr/sbin/winbindd [0x80c917c]
   #14 /usr/sbin/winbindd [0x80cb237]
   #15 /usr/sbin/winbindd [0x80c8dea]
   #16 /usr/sbin/winbindd(async_request+0x1ca) [0x80c8870]
   #17 /usr/sbin/winbindd(do_async+0xf3) [0x80cb48c]
   #18 /usr/sbin/winbindd(winbindd_uid2sid_async+0x62) [0x80d1a71]
   #19 /usr/sbin/winbindd(winbindd_uid_to_sid+0x8c) [0x80b88ff]
   #20 /usr/sbin/winbindd [0x809db58]
   #21 /usr/sbin/winbindd [0x809e564]
   #22 /usr/sbin/winbindd [0x809e3ed]
   #23 /usr/sbin/winbindd [0x809de26]
   #24 /usr/sbin/winbindd [0x809eba0]
   #25 /usr/sbin/winbindd(main+0xa03) [0x809f83d]
   #26 /lib/tls/libc.so.6(__libc_start_main+0xd0) [0x401ec210]
   #27 /usr/sbin/winbindd [0x809d261]
[2009/01/21 19:42:46,  0] lib/fault.c:dump_core(201)
  dumping core in /var/log/samba/cores/winbindd

The back trace from that error is:

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4025f8a3 in __waitpid_nocancel () from /lib/tls/libc.so.6
#2  0x4020b148 in do_system () from /lib/tls/libc.so.6
#3  0x401d296d in system () from /lib/tls/libpthread.so.0
#4  0x0814c156 in smb_panic ()
#5  0x08138269 in fault_report ()
#6  0x08138277 in sig_fault ()
#7  <signal handler called>
#8  0xffffe410 in __kernel_vsyscall ()
#9  0x401fe581 in raise () from /lib/tls/libc.so.6
#10 0x401ffe65 in abort () from /lib/tls/libc.so.6
#11 0x401f7c03 in __assert_fail () from /lib/tls/libc.so.6
#12 0x40195f02 in ldap_next_entry () from /usr/lib/libldap.so.199
#13 0x0834db9f in idmap_ldap_unixids_to_sids ()
#14 0x0834826f in idmap_backends_unixids_to_sids ()
#15 0x08348dc5 in idmap_unixids_to_sids ()
#16 0x0834abdd in idmap_uid_to_sid ()
#17 0x080d1b08 in winbindd_dual_uid2sid ()
#18 0x080c917c in child_process_request ()
#19 0x080cb237 in fork_domain_child ()
#20 0x080c8dea in schedule_async_request ()
#21 0x080c8870 in async_request ()
#22 0x080cb48c in do_async ()
#23 0x080d1777 in winbindd_sid2gid_async ()
#24 0x080b8143 in sid2gid_lookupsid_recv ()
#25 0x080cb84b in lookupsid_recv ()
#26 0x080cb392 in do_async_recv ()
#27 0x080c8d93 in async_reply_recv ()
#28 0x0809de26 in rw_callback ()
#29 0x0809eba0 in process_loop ()
#30 0x0809f83d in main ()

Our samba configuration file:

[global]
  netbios name                  = XXXXXXXX
  interfaces                    = 1.2.3.4/24
  bind interfaces only          = yes
  serverstring                  = Server %L
  winsserver                    = 1.2.3.5

# Domain-Mitgliedschaft

  security                      = DOMAIN
  workgroup                     = XXXXXXXXX
  passwordserver                = ip-of-bdc ip-of-pdc
  winbind use default domain    = yes
  admin users                   = root, administrator, @XXXXXXXX\Domänen-Admins

  printing                      = bsd
  printcap name                 = /dev/null
  show add printer wizard       = no

  ldap connection timeout = 120

  idmap domains                 = XXXXXXXX

  idmap config XXXXXXXX: default    = yes
  idmap config XXXXXXXX: range      = 10000-40000
  idmap config XXXXXXXX: readonly   = yes
  idmap config XXXXXXXX: backend    = ldap
  idmap config XXXXXXXX: ldap_url   = ldap://ip-address-of-LDAP-server
  idmap config XXXXXXXX: ldap_anon  = yes
  idmap config XXXXXXXX: ldap_base_dn = ou=Idmap,dc=xxxxxxxx,dc=xxx

[Testshare]
  path = /testshare
  comment = Liegt in /testshare
  writeable = yes
  valid users = @XXXXXXXX/somegroup


I will add the ldapsearch output for an affected user. We even tried to
delete and recreate that particular user. We have other users with 
encoded text, we cannot find a difference to other, working users,
except for uids and SIDs, of course.

dn: uid=xxxx,ou=people,ou=Berlin,dc=baua,dc=lan
sn: XXXXX
gender: M
preferredLanguage: de_DE
employeeType: XXXXXXXXX
l: XXXXXX
st: XXXXXX
postalAddress:: <some encoded string here>
homeDirectory: /nonexistent
loginShell: /bin/bash
uidNumber: 20015
gidNumber: 10726
sambaSID: S-1-5-21-101473267-2020957187-6498272-41112
uid: xxxxx
sambaMungedDial: bQAIACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABkA
 AEAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAUAAQABoACA
 ABAEMAdAB4AEMAZgBnAFAAcgBlAHMAZQBuAHQANTUxZTBiYjAYAAgAAQBDAHQAeABDAGYAZwBGAGw
 AYQBnAHMAMQAwMEUwMDAxMBYACAABAEMAdAB4AEMAYQBsAGwAYgBhAGMAawAwMDAwMDAwZRIACAAB
 AEMAdAB4AFMAaABhAGQAbwB3ADAxMDAwMDAwIgAIAAEAQwB0AHgASwBlAHkAYgBvAGEAcgBkAEwAY
 QB5AG8AdQB0ADAwMDAwMDAwKgAAAAEAQwB0AHgATQBpAG4ARQBuAGMAcgB5AHAAdABpAG8AbgBMAG
 UAdgBlAGwAIAACAAEAQwB0AHgAVwBvAHIAawBEAGkAcgBlAGMAdABvAHIAeQAwMCAAAgABAEMAdAB
 4AE4AVwBMAG8AZwBvAG4AUwBlAHIAdgBlAHIAMDAYAAIAAQBDAHQAeABXAEYASABvAG0AZQBEAGkA
 cgAwMCIABgABAEMAdAB4AFcARgBIAG8AbQBlAEQAaQByAEQAcgBpAHYAZQA0NDNhMDAgAAIAAQBDA
 HQAeABXAEYAUAByAG8AZgBpAGwAZQBQAGEAdABoADAwIgACAAEAQwB0AHgASQBuAGkAdABpAGEAbA
 BQAHIAbwBnAHIAYQBtADAwIgACAAEAQwB0AHgAQwBhAGwAbABiAGEAYwBrAE4AdQBtAGIAZQByADA
 wKAAIAAEAQwB0AHgATQBhAHgAQwBvAG4AbgBlAGMAdABpAG8AbgBUAGkAbQBlADAwMDAwMDAwLgAI
 AAEAQwB0AHgATQBhAHgARABpAHMAYwBvAG4AbgBlAGMAdABpAG8AbgBUAGkAbQBlADAwMDAwMDAwH
 AAIAAEAQwB0AHgATQBhAHgASQBkAGwAZQBUAGkAbQBlADAwMDAwMDAw
sambaHomeDrive: D:
sambaLogonScript: Netlogon.bat
sambaPrimaryGroupSID: S-1-5-21-101473267-2020957187-6498272-513
sambaDomainName: XXXXXXXXX
sambaBadPasswordCount: 0
sambaBadPasswordTime: 0
sambaUserWorkstations: abn219
street:: <some encoded string here>
gouvernmentOrganizationalPersonLocality: Xxxxxx
houseIdentifier:: IA==
roomNumber:: IA==
gouvernmentOrganizationalUnit: FB 1
gouvernmentOrganizationalUnitSubjectArea: AB 1.3
sambaPasswordHistory: E0DF98980F859724F2B8E4B2010F49FF889CD5E350B8EC558C3C39AC
 4BD541283AD6612A2A2BF1765A50EADDA354123B44A05F1511434FC0B74A57C8A075E239E33F5
 03E93B95245E5BC5EFE17D20C10E78203C6E153A3FCDDE8F5908E7F2A0B000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 00000000000000000000000000000000000000000000000000000000000000000000000000000
 000000000000000000000000000000000000000000000000000000000
sambaPwdLastSet: 1170151977
givenName: deaktiviert 
cn: deaktiviert 
gecos: deaktiviert 
shadowLastChange: 13546
sambaPwdMustChange: 1176163200
sambaAcctFlags: [UD          ]
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: gosaAccount
objectClass: ivbbentry


When I do an ldapsearch for the SID, I get this idmap entry and the above person record:

dn: sambaSID=S-1-5-21-101473267-2020957187-6498272-41112,ou=Idmap,dc=baua,dc=l
 an
objectClass: sambaIdmapEntry
objectClass: sambaSidEntry
sambaSID: S-1-5-21-101473267-2020957187-6498272-41112
uidNumber: 20015
Comment 1 Martin Welk 2009-02-11 12:08:10 UTC
Seems it's working with the old idmap configuration in 3.3.0