Menu

#756 NTLM Windows SSPI code is not thread safe

closed-fixed
http (206)
5
2013-06-21
2008-08-08
No

The NTLM Windows SSPI code uses static globals to keep track of a DLL and interface (see http_ntlm.c).

The attached patch moves the globals into the connectdata structure. The lifetime of the loaded
DLL and interface will be the the same as the previous implementation (the connection), but the race condition is removed.

Discussion

  • Constantine Sapuntzakis

    Patch for thread safe SSPI

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-08-08

    Logged In: YES
    user_id=1110
    Originator: NO

    This seems to load the DLLs a little bit more often than necessary. Won't it make more sense to add the new struct members to (somewhere in) the SessionHandle struct?

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-08-08
    • status: open --> open-accepted
     
  • Constantine Sapuntzakis

    Different take - initialize at curl_global_init time

     
  • Constantine Sapuntzakis

    Logged In: YES
    user_id=669005
    Originator: YES

    What do you think of loading the DLL once at curl_global_init() time and unloading it
    at curl_global_cleanup()?

    Patch attached.
    File Added: curl-ntlm-thread-safe-sspi-v2.diff

     
  • Yang Tse

    Yang Tse - 2008-08-10

    Logged In: YES
    user_id=1590006
    Originator: NO

    Since Constantine is certainly working on this SSPI area.

    Wouldn't it be interesting to get rid of the loadlibrary (dlopen) stuff and link with that library in the same way ws2_32 and others are used ? Its only 20 Kb more or less.

    Would this be technically possible Constantine, or is dynamic linking mandatory for some obscure reason ?

    Makefiles could be adjusted to link with 'secur32' when SSPI is required. And if someone still requires it to work on Windows NT then 'security' should be used instead of 'secur32'.

    Just thinking outloud

     
  • Constantine Sapuntzakis

    Logged In: YES
    user_id=669005
    Originator: YES

    The original motivation for going the LoadLibrary route was Windows NT 4.0/9x compatibility. NT 4.0/9x is not important for my application.

    http://curl.haxx.se/mail/lib-2005-11/0059.html

    Windows 9x doesn't have security.dll
    Windows NT 4.0 doesn't have secur32.dllf

    -Costa

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-08-11

    Logged In: YES
    user_id=1110
    Originator: NO

    Thanks! The v2 patch was applied and committed (with minor edits).

     
  • Daniel Stenberg

    Daniel Stenberg - 2008-08-11
    • status: open-accepted --> closed-fixed