Re: Bug in SMB when multiple scripts are connecting to same host

[Chris Woodbury <woodbusy () gmail com>]

David-

Sorry for the delay in getting back to you. You make a good point about the
maintainability of all those unlocks. Fortunately, those two functions are
already wrapped by another one, start_session(), so I've attached a patch
that moves the mutex to that function. For good measure, I also threw in
some comments warning users away from calling start_session_basic() and
start_session_extended() directly.

-chris


On Tue, Mar 15, 2011 at 1:45 AM, David Fifield <david () bamsoftware com>wrote:

> On Mon, Feb 28, 2011 at 01:44:34PM -0600, Chris Woodbury wrote:
> > Ron-
> >
> > Thanks for the response. Don't worry about the delay - 'better late than
> > never' is my motto ;). I hadn't thought of the lockout implications of
> > separate account lists; so, yes, you certainly wouldn't want to go that
> > route. With that in mind, I put some more thought into it, and it seems
> to
> > me that mutexes are the best approach.
> >
> > I made a patch that adds mutexes to start_session_basic() and
> > start_session_extended(). My thinking was that the first script to get
> there
> > would be responsible for finding the right account (or exhausting the
> > possibilities), and that, once that was done, the other scripts could
> follow
> > along and already have that account waiting for their get_account() call.
> I
> > had to put in an "unlock" before each of the short-circuit returns; so,
> it's
> > not exactly pretty, but it gets the job done.
>
> Could you rewrite this with wrapper functions to handle the mutexes, so
> as to get rid of the need to unlock at every single return? I'm afraid
> the way it's written now will be too hard to maintain.
>
> Ron, what do you think of Chris's solution?
>
> David Fifield

Attachment: smb_auth_mutex2.patch
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/