[PATCHES] AD: Enable TokenGroups initgroups lookup
by Ondrej Kos
Hi,
Attached find two patches for issue
https://fedorahosted.org/sssd/ticket/1568
[PATCH 1/2]: LDAP: move sdap_get_initgr_state structure to private
header
- moves the initgr state structure to private header so it can be used
also in the ad initgroups module.
[PATCH 2/2] AD: Enable TokenGroups initgroups lookup
This is first implementation of getting TokenGroups lookup working.
If all of the group SIDs that are fetched via the users TokenGroups
attribute are in sysdb, the membership is processed this way. If any of
the groups is missing in the cache, it falls back to rfc2307bis
I'd file a ticket to enhance this to look up only groups which are
missing in the sysdb, as we talked about with Jakub.
Ondra
--
Ondrej Kos
Associate Software Engineer
Identity Management - SSSD
Red Hat Czech
10 years, 7 months
mmap_cache problem
by Lukas Slebodnik
ehlo,
The big problem with mmap_cache was solved
https://lists.fedorahosted.org/pipermail/sssd-devel/2013-August/016131.html
>MAIN_PROBLEM: We know that main problem is when hash table entry refers
> to record, which hashes are different.
> (hash_key != rec->hash1 && hash_key != rec->hash2)
I found a reason of another crash reported by user
https://bugzilla.redhat.com/show_bug.cgi?id=997406#c12
Problem is broken chain and it is not related to previous bugfix.
I will try to describe example.
hash_keys will be decimal numbers and slots will be indexed with hexadecimal
numbers.
Add record R1(hash_1:1, hash_2:2) stored at slot index 0x12
Add record R2(hash_1:3, hash_2:1) stored at slot index 0x31
Add record R3(hash_1:4, hash_2:3) stored at slot index 0x43
Add record R4(hash_1:5, hash_2:4) stored at slot index 0x54
Remove record R2
Remove record R3
You can see that each record is stored ad index: concat("0x","hash_1","hash_2")
So you can easily know, which hashes record has.
Step 1)Add record R1(hash_1:1, hash_2:2) stored at slot index 0x12
hash[1] -> 0x12(R1) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> MC_INVALID_VAL
hash[3] -> MC_INVALID_VAL
hash[4] -> MC_INVALID_VAL
hash[5] -> MC_INVALID_VAL
Step 2)Add record R2(hash_1:3, hash_2:1) stored at slot index 0x31
hash[1] -> 0x12(R1) -> 0x31(R2) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x31(R2) -> MC_INVALID_VAL
hash[3] -> 0x31(R2) -> MC_INVALID_VAL
hash[4] -> MC_INVALID_VAL
hash[5] -> MC_INVALID_VAL
Step 3)Add record R3(hash_1:4, hash_2:3) stored at slot index 0x43
hash[1] -> 0x12(R1) -> 0x31(R2) -> 0x43(R3) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x31(R2) -> 0x43(R3) -> MC_INVALID_VAL
hash[3] -> 0x31(R2) -> 0x43(R3) -> MC_INVALID_VAL
hash[4] -> 0x43(R3) -> MC_INVALID_VAL
hash[5] -> MC_INVALID_VAL
Step 4)Add record R4(hash_1:5, hash_2:4) stored at slot index 0x54
hash[1] -> 0x12(R1) -> 0x31(R2) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x31(R2) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[3] -> 0x31(R2) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[4] -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[5] -> 0x54(R4) -> MC_INVALID_VAL
Step 5) Remove record R2(hash_1:3, hash_2:1) stored at slot index 0x31
a) Remove record R2 from chain starting by hash R2->hash1 (value 3)
hash[1] -> 0x12(R1) -> 0x31(R2) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x31(R2) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[3] -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[4] -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[5] -> 0x54(R4) -> MC_INVALID_VAL
b) Remove record R2 from chain starting by hash R2->hash2 (value 1)
hash[1] -> 0x12(R1) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[3] -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[4] -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[5] -> 0x54(R4) -> MC_INVALID_VAL
c) slots for record R2 are ivalidated.
Everything is OK.
Step 6) Remove record R3(hash_1:4, hash_2:3) stored at slot index 0x43
a) Remove record R3 from chain starting by hash R3->hash1 (value 4)
hash[1] -> 0x12(R1) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[3] -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[4] -> 0x54(R4) -> MC_INVALID_VAL
hash[5] -> 0x54(R4) -> MC_INVALID_VAL
b) Remove record R3 from chain starting by hash R3->hash2 (value 3)
hash[1] -> 0x12(R1) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> 0x43(R3) -> 0x54(R4) -> MC_INVALID_VAL
hash[3] -> MC_INVALID_VAL
hash[4] -> 0x54(R4) -> MC_INVALID_VAL
hash[5] -> 0x54(R4) -> MC_INVALID_VAL
c) slots for record R2 are ivalidated.
A you can see, record R3 is still in chain starting by hash with values 1,
but record R3 is invalidated and chain is broken.
Result:
hash[1] -> 0x12(R1) -> INVALIDATED_SLOT ??-> 0x54(R4) -> MC_INVALID_VAL
hash[2] -> 0x12(R1) -> INVALIDATED_SLOT ??-> 0x54(R4) -> MC_INVALID_VAL
hash[3] -> MC_INVALID_VAL
hash[4] -> 0x54(R4) -> MC_INVALID_VAL
hash[5] -> 0x54(R4) -> MC_INVALID_VAL
And my question is: How do we want to solve this problem?
I cannot find elegant simple solution.
We do not have any reference po previous member of chain.
a) We can remove record from each chain. It means that after removing record
from mmap_cache we will need to iterate over hashtable and to remove this
record from each chain.
b) We need to modify structure(s) of mmap cache.
-- either add two next references to record
-- or add reference to previous member of chain (double link list)
LS
10 years, 7 months
[PATCH] krb5: Fix warning sometimes uninitialized
by Lukas Slebodnik
ehlo,
clang found a warning in simo's krb5 refactoring patches.
src/providers/krb5/krb5_utils.c:850:9: warning: variable 'ret' is used uninitialized whenever
'if' condition is false [-Wsometimes-uninitialized]
if (kerr) {
^~~~
src/providers/krb5/krb5_utils.c:859:12: note: uninitialized use occurs here
return ret;
^~~
src/providers/krb5/krb5_utils.c:850:5: note: remove the 'if' if its condition is always true
if (kerr) {
^~~~~~~~~~
src/providers/krb5/krb5_utils.c:847:16: note: initialize the variable 'ret' to silence this
warning
errno_t ret;
LS
10 years, 7 months
[PATCH] is_dn(): free dn
by Pavel Březina
man ldap_str2dn says:
Space for dn will be obtained dynamically and should be freed by the
caller using ldap_dnfree(3).
10 years, 7 months
[PATCH] DB: Add user/group lookup by SID
by Ondrej Kos
Hi,
Attached patch adds sysdb routine to search users/groups by their SID,
which will be needed for ticket 1568.
I'm sending it now, because one of the patches I have in this working
branch (store group SID) was already written and posted on the list by
Sumit, so not to waste time again :)
--
Ondrej Kos
Associate Software Engineer
Identity Management - SSSD
Red Hat Czech
10 years, 7 months
[PATCHES] Simplify credential krb5 cache manipulation
by Simo Sorce
After the recent patches to explicitly enable the KEYRING type in SSSD I
realized that the code that manipulates ccaches had grown too much, and,
most importantly, was doing unnecessary operations already performed in
an abstract way by krb5 functions.
This patch set mostly addresses ticket #2061
The aims has been to remove as much as possible type-specific code,
resorting to type specific behavior only as an explicit exception where
necessary due to historical or other reasons.
The combined diff gives a nice total stat of:
815 insertions(+)
1529 deletions(-)
The last patch is an attempt to address ticket #2071,
It was necessary to add it here otherwise sssd will fail to operate
correctly with some templates (as noted in #2071).
However I am not sure that's the way we want to resolve the problem.
The patch aimed at maintaining as much as possible a reasonable
behavior, although the intended behavior was not really written
anywhere. Personally I would rather scrap the patch and instead provide
a new one that would simply stop creating public directories at all, I
do not think it is sssd's role to fix/create directories that should be
set up by the admin appropriately ahead of time (either manually of via
tmpfiles.d or whatever).
I will try to follow up with a proposed patch that 'simplifies' sssd
behavior instead of fixing it for #2071
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10 years, 7 months
[PATCH] Check our libraries properly resolve symbols
by Simo Sorce
While reviewing the recent big patchset I sent Sumit found out I did not
add some .c files to the ldap provider (which I didn't test as I was
working on the krb5 provider), and that broke the provider's shared
library as one symbols was missing.
We allow modules to have unresolved symbols because a number of the
symbols they use come from our sssd_be binary so they can't be fully
resolved at build time, only at runtime.
The attached patch adds a test that simulates loading most of the shared
modules we build in order to verify that there are no unresolved
symbols, that is done by manually dlopen()ing eash .so library with
RTLD_NOW so all symbols are immediately resolved.
I tested that this test properly caught the issue Sumit found before
fixing it.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
10 years, 7 months
[PATCH] AUTOTOOLS: More robust detection of inotify.
by Lukas Slebodnik
ehlo,
We checked only header file "sys/inotify" for detection whether inotify
works. Some platforms do not have built in inotify, but contain library,
which provides inotify-compatible interface.
This patch adds more robust detection of inotify in configuration time and
appends linker flags to Makefile if inotify is provided by library.
Two patches are attached. 1st is for master (1.10) and 2nd is for branch 1.9
LS
10 years, 7 months