SIGBUS Panic in smbd

[Lonnie J. Borntreger]

Thanks to Mike Black, I was able to track down the problem.  He stated, in
an email to me, that:
"I looked at it briefly and it appears to me that hashed_getpwnam() does not
strdup() the password entry.  So, the first time you call it you free the
entry in the hash table and the 2nd time you try and free it again -- bad
news.  Try strdup'ing the password inside of the hashed_getpwnam and see if
that works."

Since my system is Solaris 7, this isn't exactly the problem that I was
seeing, although it may be a valid observation on other platforms.  On
Solaris 7, hashed_getpwnam compiles the section in the #ifndef
USE_HASHED_GETPWNAM, basically it just returns getpwnam's pointer.  I think
this is a pointer to protected space which blows up the very first time the
free is called.  I did the following in _Get_Pwnam (inside the if (ret)) on
the pw_passwd and it worked perfectly.

 char *a;
 a = strdup(ret->pw_passwd);
 ret->pw_passwd = a; /* this allows all the rest of */
                     /* the logic to work unmodified */

I'm sure that this isn't the complete solution.  I imagine that the new
memory space used by the strdup should be freed at some point.

Is somebody "in charge" of this chunk of code, and can make the proper
changes (or did that person already find this)?  I haven't seen an update to
the CVS that would indicate that it was fixed.

TTFN,
Lonnie Borntreger
lonnie at borntreger.com
http://www.borntreger.com/

> -----Original Message-----
> From: samba-ntdom at samba.org [mailto:samba-ntdom at samba.org]On Behalf Of
> Lonnie J. Borntreger
> Sent: Saturday, June 26, 1999 12:00 PM
> To: Multiple recipients of list
> Subject: SIGBUS Panic in smbd
>
>
> Solaris 7
> CVS snapshot as of 6/24 - 11:45 CDT
> Full Log attached
>
> Log at error:
> [1999/06/26 10:52:27, 4] lib/domain_namemap.c:load_name_map(580)
>   load_name_map: Scanning name map /usr/local/samba/lib/domainuser.map
> [1999/06/26 10:52:27, 5] lib/domain_namemap.c:make_name_entry(441)
>   make_name_entry:,Administrator,root
> [1999/06/26 10:52:27, 5]
> lib/domain_namemap.c:unix_name_to_nt_name_info(363)
>   unix_name_to_nt_name_info: unix_name:root
> [1999/06/26 10:52:28, 0] lib/fault.c:fault_report(40)
>   ===============================================================
> [1999/06/26 10:52:28, 0] lib/fault.c:fault_report(41)
>   INTERNAL ERROR: Signal 10 in pid 22028 (2.1.0-prealpha)
>   Please read the file BUGS.txt in the distribution
> [1999/06/26 10:52:28, 0] lib/fault.c:fault_report(43)
>   ===============================================================
> [1999/06/26 10:52:28, 0] lib/util.c:smb_panic(2527)
>   PANIC: internal error
>
>
> By doing some debug statments and following the flow I found
> that the error
> occurs at username.c:_Get_Pwnam(452) which looks like:
> 450                 spass = getspnam(ret->pw_name);
> 451                 if (spass && spass->sp_pwdp) {
> 452                     free(ret->pw_passwd);
> 453                     ret->pw_passwd = strdup(spass->sp_pwdp);
> 454                 }
>
> It is dying on the free of ret->pw_passwd.  To make sure that
> the pointer
> was valid I dumped some data and saw:
>   _Get_Pwnam: s: root
>   spass->sp_namp: root
>   spass->sp_pwdp: <encrypted_passwd>
>   ret->pw_name: root
>   ret->pw_passwd: x
> This looks correct for a shadow passwd setup.
>
> Just for grins I commented out the free command.  smbd did
> not SUGBUS after
> that (however after running for about 30s it did a SIGSEGV -
> as I expected
> it would :)
>
> Any clues?  Everything looks fine as far as I can tell, but
> obviously it's
> not.
>
>
> TTFN,
> Lonnie Borntreger
> lonnie at borntreger.com
> http://www.borntreger.com/