sss_client: thread safe initialisation of sss_cli_mc_ctx

In multi threaded application, it may happen that more threads will call
function getpwuid(or similar) and sss client will not have initialized
structure for fast memory cache. This structure is initialized just once.
There isn't any problem with multi threaded application after successful
initialisation.

The race condition will happen if more threads try to initialise structure
sss_cli_mc_ctx in function sss_nss_mc_get_ctx (ctx->initialized is false)
It takes some time to initialise mmap cache: open file, get file size, mmap
file, initialize structure sss_cli_mc_ctx. One of problems is that file with
memory cache can be opened more times (file descriptor leak), but the race
condition is with initialising structure sss_cli_mc_ctx. One tread will start
to initialise this structure; another thread will think that structure is
already initialised and will check consistency of this structure. It will fail
because 1st thread did not finish initialisation. Therefore 2nd thread will
return EINVAL and will do clean up in done section: munmap, close file and
reset structure data. The 1st thread will finish an try to use memory cache,
but structure was zero initialised by 2nd thread and it will cause dereference
of NULL pointer in 1st thread (SIGSEGV) or dividing by zero in murmurhash
function(SIGFPE)

Function sss_nss_mc_get_ctx was split into two parts for simplification
of locking and unlocking. The locking is used only in new static function
sss_nss_mc_init_ctx. This function will not be called very often therefore the
same mutex is used as in other nss functions.

Resolves:
https://fedorahosted.org/sssd/ticket/2380

Reviewed-by: Michal Židek <mzidek@redhat.com>
Reviewed-by: Sumit Bose <sbose@redhat.com>

0 files changed, 0 insertions, 0 deletions