History log of /sssd/src/sss_client/nss_mc_group.c
Revision Date Author Comments Expand
ba847347cade817ee927397d82c952b51b0dcb2b 05-Aug-2015 Lukas Slebodnik <lslebodn@redhat.com>

sss_client: Update integrity check of records in mmap cache The function sss_nss_mc_get_record return copy of record from memory cache in last argument. Because we should not access data directly to avoid problems with consistency of record. The function sss_nss_mc_get_record also check whether length of record is within data area (with macro MC_CHECK_RECORD_LENGTH) However we also tried to do the same check in functions sss_nss_mc_get{gr, pw}* Pointer to end of strings in record was compared to pointer to the end of data table. But these two pointers are not within the same allocated area and does not make sense to compare them. Sometimes record can be allocated before mmaped area and sometime after. Sometimes it will return cached data and other time will fall back to responder. Resolves: https://fedorahosted.org/sssd/ticket/2743 Reviewed-by: Michal Židek <mzidek@redhat.com>

6a60e29468fc6b4043a4dc52d3aab73e8465db70 24-Nov-2014 Lukas Slebodnik <lslebodn@redhat.com>

sss_client: Fix race condition in memory cache Thread safe initialisation was fixed in ticket #2380, but there is still race condition in reinitialisation. If caches is invalidated with command sss_cache -U (-G or -E) then client code will need to reinitialize fast memory cache. Let say we have two threads. The 1st thread find out that memory cache should be reinitialized; therefore the fast memory cached is unmapped and context destroyed. In the same time, 2nd thread tried to check header of memory cache whether it is initialized and valid. As a result of previously unmapped memory the 2nd thread access out of bound memory (SEGFAULT). The destroying of fast memory cache cannot be done any time. We need to be sure that there isn't any other thread which uses mmaped memory. The new counter of active threads was added for this purpose. The state of fast memory cache was converted from boolean to three value state (UNINITIALIZED, INITIALIZED, RECYCLED) UNINITIALIZED - the fast memory cache need to be initialized. - if there is a problem with initialisation the state will not change - after successful initialisation, the state will change to INITIALIZED INITIALIZED - if the cahe was invalidated or there is any other problem was detected in memory cache header the state will change to RECYCLED and memory cache IS NOT destroyed. RECYCLED - nothing will be done is there are any active threads which may use the data from mmaped memory - if there aren't active threads the fast memory cahe is destroyed and state is changed to UNINITIALIZED. https://fedorahosted.org/sssd/ticket/2445 Reviewed-by: Michal Židek <mzidek@redhat.com>

9d876108620931e0941a115adf60bfd8d67459d9 23-Jul-2014 Lukas Slebodnik <lslebodn@redhat.com>

sss_client: Fix memory leak in nss_mc_{group,passwd} Memory leak can happen with long living clients where there are records with colliding hashes; usually LDAP servers with many users or groups. Function sss_nss_mc_get_record allocates memory that is stored into "rec", with next iteration variable rec is overriden with new record and old one is lost and cannot be freed. Example code flow: src/sss_client/nss_mc_group.c:133: alloc_arg: "sss_nss_mc_get_record" allocates memory that is stored into "rec". src/sss_client/nss_mc_common.c:216:13: alloc_fn: Storage is returned from allocation function "malloc". src/sss_client/nss_mc_common.c:216:13: var_assign: Assigning: "copy_rec" = "malloc(rec_len)". src/sss_client/nss_mc_common.c:225:9: noescape: Resource "copy_rec" is not freed or pointed-to in function "memcpy". [Note: The source code implementation of the function has been overridden by a builtin model.] src/sss_client/nss_mc_common.c:239:5: var_assign: Assigning: "*_rec" = "copy_rec". src/sss_client/nss_mc_group.c:163: noescape: Resource "rec" is not freed or pointed-to in "sss_nss_mc_next_slot_with_hash". src/sss_client/nss_mc_common.c:294:60: noescape: "sss_nss_mc_next_slot_with_hash(struct sss_mc_rec *, uint32_t)" does not free or save its pointer parameter "rec". src/sss_client/nss_mc_group.c:133: overwrite_var: Overwriting "rec" in call to "sss_nss_mc_get_record" leaks the storage that "rec" points to. src/sss_client/nss_mc_common.c:239:5: write_notnull_to_parm: Assigning: "*_rec" = "copy_rec". Reviewed-by: Michal Židek <mzidek@redhat.com> Reviewed-by: Sumit Bose <sbose@redhat.com>

90ac46f71068d131391492360a8553bdd005b5a7 01-Jul-2014 Michal Zidek <mzidek@redhat.com>

Add type parameter to DISCARD_ALIGN macro This macro will be used to suppress alignment warnings when casting pointers. fixes: https://fedorahosted.org/sssd/ticket/1359 Reviewed-by: Lukáš Slebodník <lslebodn@redhat.com>

8bf65dbab8703697c85b033beb5c189fce17b036 10-Dec-2013 Michal Zidek <mzidek@redhat.com>

Properly align buffer when storing pointers. Properly align buffer address to sizeof(char *) when storing pointers to strings. resolves: https://fedorahosted.org/sssd/ticket/1359

581de96fc30b7fe44070f17a8a73f3374d38d6ff 23-Sep-2013 Lukas Slebodnik <lslebodn@redhat.com>

mmap_cache: Use two chains for hash collision. struct sss_mc_rec had two hash members (hash1 and hash2) but only one next member. This was a big problem in case of higher probability of hash collision. structure sss_mc_rec will have two next members (next1, next2) with this patch. next1 is related to hash1 and next2 is related to hash1. Iterating over chains is changed, because we need to choose right next pointer. Right next pointer will be chosen after comparing record hashes. This behaviour is wrapped in function sss_mc_next_slot_with_hash. Adding new record to chain is also changed. The situation is very similar to iterating. We need to choose right next pointer (next1 or next2). Right next pointer will be chosen after comparing record hashes. Adding reference to next slot is wrapped in function sss_mc_chain_slot_to_record_with_hash Size of structure sss_mc_rec was increased from 32 bytes to 40 bytes. Resolves: https://fedorahosted.org/sssd/ticket/2049

13df7b9e400211c717284fb841c849ba034ed348 19-Aug-2013 Michal Zidek <mzidek@redhat.com>

mmap_cache: Off by one error. Removes off by one error when using macro MC_SIZE_TO_SLOTS and adds new macro MC_SLOT_WITHIN_BOUNDS.

e61044d99ce1e68057fda236f04a731f1f3f299a 19-Aug-2013 Michal Zidek <mzidek@redhat.com>

mmap_cache: Remove triple checks in client code. We had pattern in client code with 3 conditions that can be replaced with one.

8a5931bcc8e9034e4beb92fc9addf3f7fcf83fd6 19-Aug-2013 Michal Zidek <mzidek@redhat.com>

mmap_cache: Check data->name value in client code data->name value must be checked to prevent segfaults in case of corrupted memory cache. resolves: https://fedorahosted.org/sssd/ticket/2018

9028706a00da1bc48547e74aa872c825ac15adb2 11-Aug-2013 Michal Zidek <mzidek@redhat.com>

mmap_cache: Check if slot and name_ptr are not invalid. This patch prevents jumping outside of allocated memory in case of corrupted slot or name_ptr values. It is not proper solution, just hotfix until we find out what is the root cause of ticket https://fedorahosted.org/sssd/ticket/2018

287e76479d68db4134274d4a4fca5fe0fbc9a605 22-Nov-2012 Jan Cholasta <jcholast@redhat.com>

Fix errors reported by rpmlint

10eae23e2483733d4ca3c21f15b5bdb3f04c9839 19-Mar-2012 Simo Sorce <simo@redhat.com>

sss_client: shared memory cache group map support