Bug 450 - Segfaults if unable to connect to DC for trusted dom enumeration (security=server)
Summary: Segfaults if unable to connect to DC for trusted dom enumeration (security=se...
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control (show other bugs)
Version: 3.0.0preX
Hardware: All All
: P2 major
Target Milestone: none
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
URL: http://bugs.debian.org/208224
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-13 10:00 UTC by Steve Langasek
Modified: 2005-08-24 10:18 UTC (History)
0 users

See Also:

Attachments
Fix for segfault upon failed attempt to enumerate trusted domains (558 bytes, patch)
2003-09-13 10:06 UTC, Steve Langasek 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Langasek 2003-09-13 10:00:32 UTC 
Samba 3.0.0rc1-rc4 all appear to suffer from a segfault when an attempt to
connect to a DC for enumeration of trusted domains fails.  There is a very
simple fix for the segfault, which I'll attach shortly.

This may be tied to a change of behavior in the handling of 'security=server'
between beta2 and rc1; the user reports that in at least one case, a server that
exhibits this problem under rc3 is able to successfully connect to the server
under rc1.
Comment 1 Steve Langasek 2003-09-13 10:06:10 UTC 
Created attachment 140 [details]
Fix for segfault upon failed attempt to enumerate trusted domains

On error, we may have a NULL pointer instead of a cli_state struct.  Check for
this in enumerate_domain_trusts() rather than passing the pointer to shutdown
functions that assume a validt struct.
Comment 2 Tim Potter 2003-09-15 20:54:59 UTC 
Checked in.  Thanks vorlon!
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-02-07 09:06:21 UTC 
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:18:59 UTC 
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.