| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
This reverts commit 4662725ffef62b3b2502481438effa7c8fef9f80.
|
|
|
|
It is not very likely, that record will have the same hash1 and hash2, but it
is possible. In this situation, it does not make sense to remove record twice.
Function sss_mc_rm_rec_from_chain was not robust and sssd_nss could crash
in this situation. It was only possible if record was alone in chain.
Resolves:
https://fedorahosted.org/sssd/ticket/2049
|
|
ht_size is size of hash_table in bytes, but hash keys have type uint32_t
|
|
The code uses 2 hashes for each record, but only one hash table to
index them both, furthermore each record has only one single 'next'
pointer.
This means that in certain conditions a record main end up being on a
hash chain even though its hashes do not match the hash chain. This can
happen when another record 'drags' it in from another hash chain where
they both belong.
If the record without matching hashes happens to be the second of the
chain and the first record is removed, then the non matching record is
left on the wrong chain. On removal of the non-matching record the hash
chain will not be updated and the hash chain will end up pointing to an
invalid slot.
This slot may be later reused for another record and may not be the
first slot of this new record. In this case the hash chain will point to
arbitrary data and may cause issues if the slot is interpreted as the
head of a record.
By skipping any block that has no matching hashes upon removing the
first record in a chain we insure that dangling references cannot be
left in the hash table
Resolves:
https://fedorahosted.org/sssd/ticket/2049
|
|
Use sss_atomic_write_s() instead of write() in
sss_mc_save_corrupted(). Also unlink() the file if no data
were written.
It is better to use sss_atomic_write_s instead of write
|
|
This patch adds function to store corrupted mmap cache file to
disk for further analysis.
|
|
We introduced new way to check integrity of memcache in the
client code. We should use similiar checks in the responder.
|
|
Removes off by one error when using macro MC_SIZE_TO_SLOTS
and adds new macro MC_SLOT_WITHIN_BOUNDS.
|
|
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
|
|
sss_mc_set_recycled is a static function, that should not
be used outside nsssrv_mmap_cache.c. The sss_cache tool
is an exception, because in the case when sssd is not running,
sss_cache must invalidate the memory cache file. That is why
sss_mc_set_recycled was copied to the tools_mc_util.c
(as helper function for sss_memcache_invalidate function).
It was duplicated to allow this function to remain static
(and invisible to any .h files), so that it is not used anywhere else.
Wrong usage of this function might cause race conditions and corrupt
the cache.
I'll add comments about the duplication to the code.
|
|
This patch adds debug message for the case if sssd
fails to open old mc file for some other reason than
the file does not exist.
|
|
File descriptors leaked every time sss_mmap_cache_reinit was
called and also the old memory cache was still maped in memory
(munmap was not called). This patch adds destructor for memory
cache context to call close() and munmap() automaticly.
https://fedorahosted.org/sssd/ticket/1826
|
|
|
|
If a fatal EFAULT error is returned by the internal function that frees used
memory invalidate the whole cache and reinit it. This way we avoid further
corruption and insure clients see consistent data.
Also insure we use the right context in init() and we use talloc_zfree() in
reinit so that if the init() later fails we do not leave around a pointer
to free memory in the callers.
|
|
We should never try to invalidate an already invalid record as
internal pointers will not be consistent. Carefully test that the
record really is valid when we are fishing for free space, and
properly invalidate records or return a fatal error if something
goes wrong.
In order to make the code more robust always invalidate the whole
data space on initialization by setting all bits to 1, and make sure
to invalidate the whole last allocated slot by converting rec->len to
the number of slots instead of just the space used.
|
|
We were holding up slots when entries were invalidated directly an not through
our primitive garbage collection scheme.
|
|
Although it should enver happen that we pass in an invalid hash it
is always better to just not do anything than access memory ouf of
the hash table. It can lead to segfaults, or worse referencing
memory that should not be touched.
|
|
This is to allow to freely call mc functions even if initialization failed.
They will now gracefully fail instead of segfaulting.
|
|
https://fedorahosted.org/sssd/ticket/1704
The function is short enough so that we can simply stick with return and
release resources before returning as appropriate.
|
|
These functions can be called from the nss responder to invalidate
records that have ceased to exist or that need to be refreshed the
first time an application needs them.
|
|
Les copy/paste and chance of errors when setting basic record fields
that are shared among all object types.
|
|
https://fedorahosted.org/sssd/ticket/1584
|
|
|
|
https://fedorahosted.org/sssd/ticket/1318
|
|
https://fedorahosted.org/sssd/ticket/1209
|
|
|
|
|
|
|
|
|
|
|
