sssd-devel September 2013

sssd-devel@lists.fedorahosted.org

15 participants
94 discussions

[PATCHES] AD: Enable TokenGroups initgroups lookup
by Ondrej Kos 11 Sep '13

11 Sep '13

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

2 3

mmap_cache problem
by Lukas Slebodnik 10 Sep '13

10 Sep '13

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

3 12

[PATCH] krb5: Fix warning sometimes uninitialized
by Lukas Slebodnik 10 Sep '13

10 Sep '13

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

3 5

[PATCH] is_dn(): free dn
by Pavel Březina 10 Sep '13

10 Sep '13

man ldap_str2dn says: Space for dn will be obtained dynamically and should be freed by the caller using ldap_dnfree(3).

2 2

[PATCH] DB: Add user/group lookup by SID
by Ondrej Kos 10 Sep '13

10 Sep '13

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

2 10

[PATCH] sysdb_search_group_by_gid: obtain gid instead of uid
by Pavel Březina 10 Sep '13

10 Sep '13

This looks like copy and paste error to me. We could probably skip this attribute, but I'd like to keep the returned elements same as in sysdb_search_group_by_name().

2 2

[PATCHES] Simplify credential krb5 cache manipulation
by Simo Sorce 09 Sep '13

09 Sep '13

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

2 10

[PATCH] Check our libraries properly resolve symbols
by Simo Sorce 09 Sep '13

09 Sep '13

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

3 15

[PATCH] AUTOTOOLS: More robust detection of inotify.
by Lukas Slebodnik 09 Sep '13

09 Sep '13

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

3 4

[PATCHES] Improve portability of autoconf and automake
by Lukas Slebodnik 09 Sep '13

09 Sep '13

ehlo Patches are attached. LS

4 10

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel September 2013