diff options
Diffstat (limited to 'crypto/krb5/doc/thread-safe.txt')
| -rw-r--r-- | crypto/krb5/doc/thread-safe.txt | 241 |
1 files changed, 0 insertions, 241 deletions
diff --git a/crypto/krb5/doc/thread-safe.txt b/crypto/krb5/doc/thread-safe.txt deleted file mode 100644 index d6c8c6eabd36..000000000000 --- a/crypto/krb5/doc/thread-safe.txt +++ /dev/null @@ -1,241 +0,0 @@ -[May be out of date. Last significant update: Jan 2005.] - -In general, it's assumed that the library initialization function (if -initialization isn't delayed) and the library finalization function -are run in some thread-safe fashion, with no other parts of the -library in question in use. (If dlopen or dlsym in one thread starts -running the initializer, and then dlopen/dlsym in another thread -returns and lets you start accessing functions or data in the library -before the initializer is finished, that really seems like a -dlopen/dlsym bug.) - -It's also assumed that if library A depends on library B, then library -B's initializer runs first, and its finalizer last, whether loading -dynamically at run time or at process startup/exit. (It appears that -AIX 4.3.3 may violate this, at least when we use gcc's -constructor/destructor attributes in shared libraries.) - -Support for freeing the heap storage allocated by a library has NOT, -in general, been written. There are hooks, but often they ignore some -of the library's local storage, mutexes, etc. - -If shared library finalization code doesn't get run at all at dlclose -time, or if we can't use it because the execution order is wrong, then -you'll get memory leaks. Deal with it. - -Several debugging variables that are not part of our official API are -not protected by mutexes. In general, the only way to set them is by -changing the sources and recompiling, which obviously has no run-time -thread safety issues, or by stopping the process under a debugger, -which we blithely assert is "safe enough". - -Debug code that we don't normally enable may be less thread safe than -might be desired. For example, multiple printf calls may be made, -with the assumption that the output will not be intermixed with output -from some other thread. Offhand, I'm not aware of any cases where -debugging code is "really" unsafe, as in likely to crash the program -or produce insecure results. - -Various libraries may call assert() and abort(). This should only be -for "can't happen" cases, and indicate programming errors. In some -cases, the compiler may be able to infer that the "can't happen" cases -really can't happen, and drop the calls, but in many cases, this is -not possible. - -There are cases (e.g., in the com_err library) where errors arising -when dealing with other errors are handled by calling abort, for lack -of anything better. We should probably clean those up someday. - -Various libraries call getenv(). This is perfectly safe, as long as -nothing is calling setenv or putenv or what have you, while multiple -threads are executing. Of course, that severely curtails the ability -to control our libraries through that "interface". - -Various libraries call the ctype functions/macros (isupper, etc). It -is assumed that the program does not call setlocale, or does so only -while the program is still single-threaded or while calls into the -Kerberos libraries are not in progress. - -The Windows thread safety support is unfinished. - -I'm assuming that structure fields that are never written to (e.g., -after a structure has been initialized and *then* made possibly -visible to multiple threads) are safe to read from one thread while -another field is being updated by another thread. If that's not the -case, some more work is needed (and I'd like details on why it's not -safe). - ----------------- - -libcom_err - -Issues: - -The callback hook support (set_com_err_hook, reset_com_err_hook, and -calls to com_err and com_err_va) uses a mutex to protect the handle on -the hook function. As a side effect of this, if a callback function -is registered which pops up a window and waits for the users' -acknowledgement, then other errors cannot be reported by other threads -until after the acknowledgement. This could be fixed with -multiple-reader-one-writer type locks, but that's a bit more -complicated. - -The string returned by error_message may be per-thread storage. It -can be passed off between threads, but it shouldn't be in use by any -thread by the time the originating thread calls error_message again. - -Error tables must no longer be in use (including pointers returned by -error_message) when the library containing them is unloaded. - -Temporary: A flag variable has been created in error_message.c which -is used to try to catch cases where remove_error_table is called after -the library finalization function. This generally indicates -out-of-order execution of the library finalization functions. The -handling of this flag is not thread-safe, but if the finalization -function is called, other threads should in theory be finished with -this library anyways. - -Statics: error_message.c, com_err.c, covered above. - ----------------- - -libprofile (and its use in libkrb5) - -Does no checks to see if it's opened multiple instances of the same -file under different names. Does not guard against trying to open a -file while another thread or process is in the process of replacing -it, or two threads trying to update a file at the same time. The -former should be pretty safe on UNIX with atomic rename, but on -Windows there's a race condition; there's a window (so to speak) where -the filename does not correspond to an actual file. - -Statics: prof_file.c, a list of opened config files and their parse -trees, and a mutex to protect it. - ----------------- - -libk5crypto - -Uses ctype macros; what happens if the locale is changed in a -multi-threaded program? - -Debug var in pbkdf2.c. - -Statics: pbkdf2.c: debug variable. - -Statics: crypto_libinit.c: library initializer aux data. - ----------------- - -libkrb5 - -(TBD) - -Uses: ctype macros - -Uses: getaddrinfo, getnameinfo. According to current specifications, -getaddrinfo should be thread-safe; some implementations are not, and -we're not attempting to figure out which ones. NetBSD 1.6, for -example, had an unsafe implementation. - -Uses: res_ninit, res_nsearch. If these aren't available, the non-'n' -versions will be used, and they are sometimes not thread-safe. - -Uses: mkstemp, mktemp -- Are these, or our uses of them, likely to be -thread-safe? - -Uses: sigaction - -The use of sigaction is in the code prompting for a password; we try -to catch the keyboard interrupt character being used and turn it into -an error return from that function. THIS IS NOT THREAD-SAFE. - -Uses: tcgetattr, tcsetattr. This is also in the password-prompting -code. These are fine as long as no other threads are accessing the -same terminal at the same time. - -Uses: fopen. This is thread-safe, actually, but a multi-threaded -server is likely to be using lots of file descriptors. On 32-bit -Solaris platforms, fopen will not work if the next available file -descriptor number is 256 or higher. This can cause the keytab code to -fail. - -Statics: prompter.c: interrupt flag - -Statics: ccdefops.c: default operations table pointer - -Statics: ktdefname.c: variable to override default keytab name, NO -LOCKING. DON'T TOUCH THESE VARIABLES, at least in threaded programs. - -Statics: conv_creds.c: debug variable - -Statics: sendto_kdc.c: debug variable, in export list for KDC - -Statics: parse.c: default realm cache, changed to not cache - -Statics: krb5_libinit.c: lib init aux data - -Statics: osconfig.c: various internal variables, probably should be const - -Statics: init_ctx.c: "brand" string; not written. - -Statics: cc_memory.c: list of caches, with mutex. - -Statics: c_ustime.c: last timestamp, to implement "microseconds must -always increment" - -Statics: ktbase.c, ccbase.c, rc_base.c: type registries and mutexes. - ----------------- - -libgssapi_krb5 - -(TBD) - -Uses: ctype macros - -Statics: acquire_cred.c: name of keytab to use, and mutex. - -Statics: gssapi_krb5.c: - -Statics: init_sec_context.c: - -Statics: set_ccache.c: - -Statics: gssapi_generic.c: OID definitions, non-const by -specification. We probably could make them const anyways. - -The keytab name saved away by krb5_gss_register_acceptor_identity is -global and protected by a mutex; the ccache name stored by -gss_krb5_ccache_name is per-thread. This inconsistency is due to the -anticipated usage patterns. - -The old ccache name returned by gss_krb5_ccache_name if the last -parameter is not a null pointer is also stored per-thread, and will be -discarded at the next call to that routine from the same thread, or at -thread termination. - -Needs work: check various objects for thread safety - ----------------- - -libgssrpc - -New version is in place. Ignore it for now? - ----------------- - -libkadm5* -libkdb5 - -Skip these for now. We may want the KDC libraries to be thread-safe -eventually, so the KDC can take better advantage of hyperthreaded or -multiprocessor systems. - ----------------- - -libapputils -libss - -Used by single-threaded programs only (but see above re KDC). Don't -bother for now. |