Thanks guys! Thanks Andrew for the detailed explanation...
Jeremy: Does this mean that you might consider a fix in the code for this? I'm guessing that this is the same problem that creaps up with Terminal Services/Citrix occasionally as well? I currently have a test environment where I can easily duplicate the problem...so if there's anything that needs to be tested, please let me know! I don't think I'll be making it to SambaXP, but if I can find a way to send you guys a frosty beverage, I'll do so! -David >>> Jeremy Allison <[EMAIL PROTECTED]> 04/12/05 8:20 PM >>> On Wed, Apr 13, 2005 at 10:18:19AM +1000, Andrew Bartlett wrote: > > We should not need that - the NTLMSSP and SPNEGO code does not use piles > of static variables, it's just the one context that is the problem. > All you need to do is change 'global_ntlmssp_state' into something keyed > off that VUID. See it's use in reply_spnego_negotiate() and > reply_spnego_auth(). Ok, thanks for the hints. > Just make sure you don't treat this new vuid as 'real' - I added a > 'finished_sesssetup' flag on the VUID in Samba4, and use two different > lookup functions, one for the rest of samba, and one for just the > session setup. Don't worry, I *write* the original VUID code in Samba :-). I do know how it's used :-) :-). > The next issue I need to tackle in Samba4 is that of resource > consumption - too many half-completed NTLMSSP logins. But as we allow > guest logins anyway, it's not much worse than can already be done. Yeah, I was thinking about DOS attacks there, but the worst that can happen in 65534 half-open connections. Not too bad. Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
