[SSSD] Re: [PATCH] sss_idmap-tests: Fix segmentation fault
On Wed, Feb 17, 2016 at 05:29:50PM +0100, Lukas Slebodnik wrote: > ehlo, > > simple patch is attached. > > I can reproduce it only with clang. > But it's typical off by one error. > > sh$ ./sss_idmap-tests > Running suite(s): IDMAP > Segmentation fault (core dumped) > > Running suite(s): IDMAP > ==2644== Process terminating with default action of signal 11 (SIGSEGV) > ==2644== Access not within mapped region at address 0xA08F430 > ==2644==at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) > ==2644==by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices > (sss_idmap-tests.c:451) > ==2644==by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) > ==2644==by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) > ==2644==by 0x4061EE: main (sss_idmap-tests.c:965) > ==2644== If you believe this happened as a result of a stack > ==2644== overflow in your program's main thread (unlikely but > ==2644== possible), you can try to increase the size of the > ==2644== main thread stack using the --main-stacksize= flag. > ==2644== The main thread stack size used in this run was 8388608. > > LS > From 10b1603e94a8785954f53b17f1e402b3019b29fa Mon Sep 17 00:00:00 2001 > From: Lukas Slebodnik > Date: Wed, 17 Feb 2016 17:23:37 +0100 > Subject: [PATCH] sss_idmap-tests: Fix segmentation fault > > I can reproduce it only with clang. > But it's tipical off by one error. > > sh$ ./sss_idmap-tests > Running suite(s): IDMAP > Segmentation fault (core dumped) > > Running suite(s): IDMAP > ==2644== Process terminating with default action of signal 11 (SIGSEGV) > ==2644== Access not within mapped region at address 0xA08F430 > ==2644==at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) > ==2644==by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices > (sss_idmap-tests.c:451) > ==2644==by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) > ==2644==by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) > ==2644==by 0x4061EE: main (sss_idmap-tests.c:965) > ==2644== If you believe this happened as a result of a stack > ==2644== overflow in your program's main thread (unlikely but > ==2644== possible), you can try to increase the size of the > ==2644== main thread stack using the --main-stacksize= flag. > ==2644== The main thread stack size used in this run was 8388608. > --- > src/tests/sss_idmap-tests.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/tests/sss_idmap-tests.c b/src/tests/sss_idmap-tests.c > index > 900b7bff1cd4f3c6f9cdffc4b012864d05e72913..885913645ed286636758f3f48a5a62d87cc9ab75 > 100644 > --- a/src/tests/sss_idmap-tests.c > +++ b/src/tests/sss_idmap-tests.c > @@ -427,8 +427,8 @@ START_TEST(idmap_test_sid2uid_additional_secondary_slices) > struct TALLOC_CTX *tmp_ctx; > const char *dom_prefix = "S-1-5-21-1-2-3"; > const int max_rid = 80; > -const char *sids[max_rid]; > -unsigned int ids[max_rid]; > +const char *sids[max_rid + 1]; > +unsigned int ids[max_rid + 1]; ACK. I'll add the CI link later for completeness. bye, Sumit > > tmp_ctx = talloc_new(NULL); > fail_unless(tmp_ctx != NULL, "Out of memory."); > -- > 2.5.0 > > ___ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] [PATCH] subdomains: inherit ldap_krb5_keytab
Hi,
if a different keytab than /etc/krb5.keytab is used e.g. with the AD
provider the subdomains still try to use keys from /etc/krb5.keytab to
connect to e.g. the LDAP server of the subdomain. But id
/etc/krb5.keytab is not present or does not contain suitable keys this
will fails. As a work-around it might be possible to change
default_keytab_name in /etc/krb5.conf but this will change the default
globally and only works for a single file. If e.g. there are 2 AD
domains with alternative keytabs configured this won't work.
The attached patch allows to inherit the setting of ldap_krb5_keytab (or
krb5_keytab) to the subdomains.
bye,
Sumit
From d323a89b692e481d9c47c47d35c15d19bf9d2089 Mon Sep 17 00:00:00 2001
From: Sumit Bose
Date: Wed, 17 Feb 2016 16:40:57 +0100
Subject: [PATCH] subdomains: inherit ldap_krb5_keytab
If a non-default keytab is configured for the parent domain the
subdomains will still use the default keytab because the alternative
keytab is not inherited. As a consequence SSSD might not be able to
connect to services in the subdomain because the default keytab is
either not present or does not have suitable keys.
---
src/man/sssd.conf.5.xml | 4
src/providers/ldap/sdap.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml
index
e03580bf7814c8e3a297dcfbcb5b50092cc3a8c7..c6ed2e0eefdac701168c71c975c55787ec6fb6c3
100644
--- a/src/man/sssd.conf.5.xml
+++ b/src/man/sssd.conf.5.xml
@@ -530,6 +530,10 @@
ldap_user_principal
+ldap_krb5_keytab (the value of krb5_keytab will be
+used if ldap_krb5_keytab is not set explicitly)
+
+
Example:
subdomain_inherit = ldap_purge_cache_timeout
diff --git a/src/providers/ldap/sdap.c b/src/providers/ldap/sdap.c
index
f9b9ff7e6913c406547f36d341300b936e121693..55ba6702af396c6fac3986d254e726b6372586ce
100644
--- a/src/providers/ldap/sdap.c
+++ b/src/providers/ldap/sdap.c
@@ -250,6 +250,7 @@ static void sdap_inherit_basic_options(char
**inherit_opt_list,
int inherit_options[] = {
SDAP_PURGE_CACHE_TIMEOUT,
SDAP_AD_USE_TOKENGROUPS,
+SDAP_KRB5_KEYTAB,
SDAP_OPTS_BASIC /* sentinel */
};
int i;
--
2.1.0
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] [sssd-1-13] [PATCH] UTIL: Backport error code ERR_ACCOUNT_LOCKED
ehlo,
Attached patch fixes failures in 1.13 branch
http://sssd-ci.duckdns.org/logs/job/37/45/summary.html
LS
>From 9db80c419a357f6b147e3595e1e063f6d0e2a2ff Mon Sep 17 00:00:00 2001
From: Lukas Slebodnik
Date: Wed, 17 Feb 2016 17:58:10 +0100
Subject: [PATCH] UTIL: Backport error code ERR_ACCOUNT_LOCKED
Required by:
https://fedorahosted.org/sssd/ticket/2839
---
src/util/util_errors.c | 1 +
src/util/util_errors.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/util/util_errors.c b/src/util/util_errors.c
index
1d684d387b90b8db37609d5bc022e06fcac708f9..59ae63ab8d6e834a772349b162bf282f9a4f1c72
100644
--- a/src/util/util_errors.c
+++ b/src/util/util_errors.c
@@ -82,6 +82,7 @@ struct err_string error_to_str[] = {
{ "Address family not supported" }, /* ERR_ADDR_FAMILY_NOT_SUPPORTED */
{ "Message sender is the bus" }, /* ERR_SBUS_SENDER_BUS */
{ "Subdomain is inactive" }, /* ERR_SUBDOM_INACTIVE */
+{ "Account is locked" }, /* ERR_ACCOUNT_LOCKED */
{ "AD renewal child failed" }, /* ERR_RENEWAL_CHILD */
{ "ERR_LAST" } /* ERR_LAST */
};
diff --git a/src/util/util_errors.h b/src/util/util_errors.h
index
5c02fdd8b4c6e0c59f7fd6f66a3fc8a8e48dc607..05791f2f08f107a8b4830b810b8826983763174f
100644
--- a/src/util/util_errors.h
+++ b/src/util/util_errors.h
@@ -104,6 +104,7 @@ enum sssd_errors {
ERR_ADDR_FAMILY_NOT_SUPPORTED,
ERR_SBUS_SENDER_BUS,
ERR_SUBDOM_INACTIVE,
+ERR_ACCOUNT_LOCKED,
ERR_RENEWAL_CHILD,
ERR_LAST/* ALWAYS LAST */
};
--
2.5.0
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: [sssd-1-13] [PATCH] UTIL: Backport error code ERR_ACCOUNT_LOCKED
On 02/17/2016 06:01 PM, Lukas Slebodnik wrote: ehlo, Attached patch fixes failures in 1.13 branch http://sssd-ci.duckdns.org/logs/job/37/45/summary.html LS LGTM, will wait for the 1.13 CI to finish before acking. Michal ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: [PATCH] sss_idmap-tests: Fix segmentation fault
On Wed, Feb 17, 2016 at 05:37:51PM +0100, Sumit Bose wrote: > On Wed, Feb 17, 2016 at 05:29:50PM +0100, Lukas Slebodnik wrote: > > ehlo, > > > > simple patch is attached. > > > > I can reproduce it only with clang. > > But it's typical off by one error. > > > > sh$ ./sss_idmap-tests > > Running suite(s): IDMAP > > Segmentation fault (core dumped) > > > > Running suite(s): IDMAP > > ==2644== Process terminating with default action of signal 11 (SIGSEGV) > > ==2644== Access not within mapped region at address 0xA08F430 > > ==2644==at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) > > ==2644==by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices > > (sss_idmap-tests.c:451) > > ==2644==by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) > > ==2644==by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) > > ==2644==by 0x4061EE: main (sss_idmap-tests.c:965) > > ==2644== If you believe this happened as a result of a stack > > ==2644== overflow in your program's main thread (unlikely but > > ==2644== possible), you can try to increase the size of the > > ==2644== main thread stack using the --main-stacksize= flag. > > ==2644== The main thread stack size used in this run was 8388608. > > > > LS > > > From 10b1603e94a8785954f53b17f1e402b3019b29fa Mon Sep 17 00:00:00 2001 > > From: Lukas Slebodnik > > Date: Wed, 17 Feb 2016 17:23:37 +0100 > > Subject: [PATCH] sss_idmap-tests: Fix segmentation fault > > > > I can reproduce it only with clang. > > But it's tipical off by one error. > > > > sh$ ./sss_idmap-tests > > Running suite(s): IDMAP > > Segmentation fault (core dumped) > > > > Running suite(s): IDMAP > > ==2644== Process terminating with default action of signal 11 (SIGSEGV) > > ==2644== Access not within mapped region at address 0xA08F430 > > ==2644==at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) > > ==2644==by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices > > (sss_idmap-tests.c:451) > > ==2644==by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) > > ==2644==by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) > > ==2644==by 0x4061EE: main (sss_idmap-tests.c:965) > > ==2644== If you believe this happened as a result of a stack > > ==2644== overflow in your program's main thread (unlikely but > > ==2644== possible), you can try to increase the size of the > > ==2644== main thread stack using the --main-stacksize= flag. > > ==2644== The main thread stack size used in this run was 8388608. > > --- > > src/tests/sss_idmap-tests.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/src/tests/sss_idmap-tests.c b/src/tests/sss_idmap-tests.c > > index > > 900b7bff1cd4f3c6f9cdffc4b012864d05e72913..885913645ed286636758f3f48a5a62d87cc9ab75 > > 100644 > > --- a/src/tests/sss_idmap-tests.c > > +++ b/src/tests/sss_idmap-tests.c > > @@ -427,8 +427,8 @@ > > START_TEST(idmap_test_sid2uid_additional_secondary_slices) > > struct TALLOC_CTX *tmp_ctx; > > const char *dom_prefix = "S-1-5-21-1-2-3"; > > const int max_rid = 80; > > -const char *sids[max_rid]; > > -unsigned int ids[max_rid]; > > +const char *sids[max_rid + 1]; > > +unsigned int ids[max_rid + 1]; > > ACK. I'll add the CI link later for completeness. And here we are http://sssd-ci.duckdns.org/logs/job/37/48/summary.html . bye, Sumit ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Announcing SSSD 1.11.8
=== SSSD 1.11.8 === The SSSD team is proud to announce the release of version 1.11.8 of the System Security Services Daemon. As always, the source is available from https://fedorahosted.org/sssd == Feedback == Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users == Highlights == * This release focuses on backporting bug fixes from the 1.12 and 1.13 releases. At the moment, the SSSD upstream does not plan on releasing 1.11.9, barring security issues or regressions in this release. We recommend that all users of 1.11 upgrade to 1.12 or 1.13. * Several bugs related to using id_provider=ldap together with ID mapping enabled were fixed * Fixed a potential use-after-free error in the nested groups resolution code * The service restart code in the main "sssd" process was improved * The PAC responder can be built with MIT Kerberos versions 1.13 and 1.14 * A potential segfault in the memberof ldb plugin was fixed * The LDAP child no longer leaves a stray temporary file behind in case acquiring the credentials fails * The sudo responder works correctly even for users or groups whose name contains an LDAP special character such as ) * The autofs responder now works even with setups that enable the default_domain_suffix option * A memory leak in the NSS responder when a non-existing netgroup was requested is fixed in this release * The SSSD no longer leaks a file descriptor if service discovery times out when discovering an LDAP server * The sudo responder fixed the logic to sort entries with the sudoOrder attribute to match the sudo's native LDAP code == Documentation Changes == * The ldap_use_tokengroups option defaults to false in the generic LDAP provider. Previously, both the AD and LDAP provider (with ldap_schema set to ad) attempted to use the tokenGroups, resulting in numerous bugs. == Tickets Fixed == * https://fedorahosted.org/sssd/ticket/2412 Error processing universal groups with cross-domain membership in SSSD server mode * https://fedorahosted.org/sssd/ticket/2471 RHEL6.6 sssd (1.11) fails if IPA permissions and roles have the same name * https://fedorahosted.org/sssd/ticket/2484 Password change over ssh doesn't work with OTP and FreeIPA * https://fedorahosted.org/sssd/ticket/2448 MAN: If ldap_group_base is set, tokengroups might not be able to convert all GIDs to names * https://fedorahosted.org/sssd/ticket/2445 Race condition while invalidating memory cache in client code * https://fedorahosted.org/sssd/ticket/2492 Group membership gets lost in IPA server mode * https://fedorahosted.org/sssd/ticket/2573 Use after free in proxy provider. * https://fedorahosted.org/sssd/ticket/2611 sssd_be dumping core if enumeration times out * https://fedorahosted.org/sssd/ticket/2525 Monitor SIGKILL timer issue and service restart failure * https://fedorahosted.org/sssd/ticket/2572 [abrt] sssd-common: talloc_abort(): sssd killed by SIGABRT * https://fedorahosted.org/sssd/ticket/2430 sssd segfaults repeatedly with error 4 in memberof.so * https://fedorahosted.org/sssd/ticket/1096 Clock skew in krb5 auth should result in offline operation, not failure * https://fedorahosted.org/sssd/ticket/2592 ccname_file_dummy is not unlinked on error * https://fedorahosted.org/sssd/ticket/2613 sysdb sudo search doesn't escape special characters * https://fedorahosted.org/sssd/ticket/2625 Sudo responder does not respect filter_users and filter_groups * https://fedorahosted.org/sssd/ticket/2643 autofs provider fails when default_domain_suffix and use_fully_qualified_names set * https://fedorahosted.org/sssd/ticket/2634 sssd nss responder gets wrong number of secondary groups * https://fedorahosted.org/sssd/ticket/2644 ignore_group_members doesn't work for subdomains * https://fedorahosted.org/sssd/ticket/2659 IPA enumeration provider crashes * https://fedorahosted.org/sssd/ticket/2663 id lookup for non-root domain users doesn't return all groups on first attempt * https://fedorahosted.org/sssd/ticket/2681 SSSD cache is not updated after user is deleted from ldap server * https://fedorahosted.org/sssd/ticket/2744 cleanup_groups should sanitize dn of groups * https://fedorahosted.org/sssd/ticket/2800 Relax POSIX check * https://fedorahosted.org/sssd/ticket/2803 Memory leak / possible DoS with krb auth. * https://fedorahosted.org/sssd/ticket/2792 SSSD is not closing sockets properly * https://fedorahosted.org/sssd/ticket/2888 SRV lookups with id_provider=proxy and auth_provider=krb5 * https://fedorahosted.org/sssd/ticket/2865
[SSSD] Re: [PATCH] IDMAP: Add minor performance improvements
On 02/15/2016 06:19 PM, Sumit Bose wrote:
On Tue, Jan 26, 2016 at 05:35:06PM +0100, Pavel Reichl wrote:
>Hello,
>
>please see simple patch attached.
Hi Pavel,
sorry for the delay. See comments below.
bye,
Sumit
Thanks for checking and for comments. Amended patch is attached.
Bye.
>From bf09421bcd4e5be5fad4d907ccdd8f99f7999b88 Mon Sep 17 00:00:00 2001
From: Pavel Reichl
Date: Tue, 26 Jan 2016 11:28:22 -0500
Subject: [PATCH] IDMAP: Add minor performance improvements
Some ID ranges are precalculated when ID mapping is being initialized.
This patch utilizes these (helper) ranges when new domains are generated
if appropriate.
---
src/lib/idmap/sss_idmap.c | 95 +--
1 file changed, 84 insertions(+), 11 deletions(-)
diff --git a/src/lib/idmap/sss_idmap.c b/src/lib/idmap/sss_idmap.c
index e3e9972b802748770a5f7440fa8ddc8ba75d3362..5c84f2a997e5134583ad8c5fea72b02c7e1e52a2 100644
--- a/src/lib/idmap/sss_idmap.c
+++ b/src/lib/idmap/sss_idmap.c
@@ -89,6 +89,49 @@ static char *idmap_strdup(struct sss_idmap_ctx *ctx, const char *str)
return new;
}
+static bool ranges_eq(const struct idmap_range_params *a,
+ const struct idmap_range_params *b)
+{
+if (a == NULL || b == NULL) {
+return false;
+}
+
+if (a->first_rid == b->first_rid
+&& a->min_id == b->min_id
+&& a->max_id == b->max_id) {
+return true;
+}
+
+return false;
+}
+
+static enum idmap_error_code
+construct_range(struct sss_idmap_ctx *ctx,
+const struct idmap_range_params *src,
+char *id,
+struct idmap_range_params **_dst)
+{
+struct idmap_range_params *dst;
+
+if (src == NULL || id == NULL || _dst == NULL) {
+return IDMAP_ERROR;
+}
+
+dst = ctx->alloc_func(sizeof(struct idmap_range_params), ctx->alloc_pvt);
+if (dst == NULL) {
+return IDMAP_OUT_OF_MEMORY;
+}
+
+dst->min_id = src->min_id;
+dst->max_id = src->max_id;
+dst->first_rid = src->first_rid;
+dst->next = NULL;
+dst->range_id = id;
+
+*_dst = dst;
+return IDMAP_SUCCESS;
+}
+
static bool id_is_in_range(uint32_t id,
struct idmap_range_params *rp,
uint32_t *rid)
@@ -232,6 +275,20 @@ static void free_helpers(struct sss_idmap_ctx *ctx,
}
}
+static struct idmap_range_params*
+get_helper_by_id(struct idmap_range_params *helpers, const char *id)
+{
+struct idmap_range_params *it;
+
+for (it = helpers; it != NULL; it = it->next) {
+if (strcmp(it->range_id, id) == 0) {
+return it;
+}
+}
+
+return NULL;
+}
+
static void sss_idmap_free_domain(struct sss_idmap_ctx *ctx,
struct idmap_domain_info *dom)
{
@@ -854,30 +911,44 @@ static bool comp_id(struct idmap_range_params *range_params, long long rid,
static enum idmap_error_code
get_range(struct sss_idmap_ctx *ctx,
+ struct idmap_range_params *helpers,
const char *dom_sid,
long long rid,
struct idmap_range_params **_range)
{
-char *secondary_name;
+char *secondary_name = NULL;;
enum idmap_error_code err;
int first_rid;
struct idmap_range_params *range;
+struct idmap_range_params *helper;
first_rid = (rid / ctx->idmap_opts.rangesize) * ctx->idmap_opts.rangesize;
secondary_name = generate_sec_slice_name(ctx, dom_sid, first_rid);
if (secondary_name == NULL) {
-return IDMAP_OUT_OF_MEMORY;
+err = IDMAP_OUT_OF_MEMORY;
+goto error;
}
-err = generate_slice(ctx, secondary_name, first_rid, &range);
-if (err == IDMAP_OUT_OF_SLICES) {
-ctx->free_func(secondary_name, ctx->alloc_pvt);
-return err;
+helper = get_helper_by_id(helpers, secondary_name);
+if (helper != NULL) {
+/* Utilize helper's range. */
+err = construct_range(ctx, helper, secondary_name, &range);
+} else {
+/* Have to generate a whole new range. */
+err = generate_slice(ctx, secondary_name, first_rid, &range);
+}
+
+if (err != IDMAP_SUCCESS) {
+goto error;
}
*_range = range;
return IDMAP_SUCCESS;
+
+error:
+ctx->free_func(secondary_name, ctx->alloc_pvt);
+return err;
}
static enum idmap_error_code
@@ -904,9 +975,7 @@ spawn_dom(struct sss_idmap_ctx *ctx,
it = ctx->idmap_domain_info;
while (it != NULL) {
/* Find the newly added domain. */
-if (it->range_params.first_rid == range->first_rid
-&& it->range_params.min_id == range->min_id
-&& it->range_params.max_id == range->max_id) {
+if (ranges_eq(&it->range_params, range)) {
/* Share helpers. */
it->helpers = parent->helpers;
@@ -958,8 +1027,7 @@ add_dom_for_sid(struct sss_idmap_ctx *ctx,
goto done;
}
-/* todo optimize */
-
[SSSD] Design stub: performance enhancements for 1.14
Hi, I would like to get some opinions on where I'm heading with the performance enhancements for 1.14. Please note this is /not/ a complete design page. The goal is to just identify some blockers first before I spend more time working on this feature, even though I already discussed the page with some developers (thanks!). If we agree this is the way to go, I will polish the design page as I work on the feature. I've started the design page here: https://fedorahosted.org/sssd/wiki/DesignDocs/OneFourteenPerformanceImprovements For your convenience, I've included the text below as well: = Feature Name = SSSD Performance enhancements for the 1.14 release Related ticket(s): * https://fedorahosted.org/sssd/ticket/2602 * https://fedorahosted.org/sssd/ticket/2062 === Problem statement === At the moment SSSD doesn't perform well in large environments. Most of the use-cases we've had reported revolved around logins of users who are members of large groups or a large amount of groups. Another reported use-case was the time it takes to resolve a large group. While workarounds are available for some of the issues (such as using `ignore_group_members` for resolution of large groups), our goal is to be able to perform well without these workarounds. === Use cases === * User who is a member of a large amount of AD groups logs in to a Linux server that is a member of the AD domain. * User who is a member of a large amount of AD or IPA groups logs in to a Linux server that is a member of an IPA domain with a trust relationship to an AD domain * Administrator of a Linux server runs "ls -l" in a directory where files are owned by a large group. An example would be group called "students" in an university setup === Overview of the solution === During performance analysis with systemtap, we found out that the biggest delay happens when SSSD writes an entry to the cache. We can't skip cache writes completely, even if no attributes changed, because we store also the expiration timestamps in the cache. Also, even if a single attribute (like the timestamp) changes, ldb would need to unpack the whole entry, change the record, pack it back and then write the whole blob. In order to mitigate the costly cache writes, we should avoid writing the whole cache entry on every cache update. To avoid this, we will split the monolithic ldb cache representing the sysdb cache into two ldb files. One would contain the entry itself and would be fully synchronous. The other (new one) would only contain the timestamps and would be open using the `LDB_FLG_NOSYNC` to avoid synchronous cache writes. This would have two advantages: 1. If we detect that the entry hasn't changed on the LDAP server at all, we could avoid writing into the main ldb cache which would still be costly. 1. The writes to the new async ldb cache would be much faster, because the entry is smaller and because the writes wouldn't call `fsync()` due to using the async flag, but rather rely on the underlying filesystem to sync the data to the disk. On SSSD shutdown, we would write a canary to the cache, denoting graceful shutdown. On SSSD startup, if the canary wasn't found, we would just ditch the timestamp cache, which would result in refresh and write of the entry on the next lookup. Other minor performance enhancements might include: * using syncrepl in the server mode for HBAC rules and external groups in refreshAndPersistMode. This would provide performance benefit for legacy clients that rely on server's HBAC rules for access control. * using syncrepl in the server mode for external groups in refreshAndPersistMode. This would mainly simplify the external groups handling, rather than improve performance * A lot of time is spent looking up attributes in the `sysdb_attrs` array. This is something we might want to optimize after we're done with the cache writes. * We might even consider offering syncrepl in refreshOnly mode as an client-side option for enumeration. However, this would have to be an opt-in because every refresh causes the server to walk the changelog since the last refresh operation. Enabling this option on all clients would trash the server performance. The basic idea is to use a combination of the operational `modifyTimestamp` attribute and checking the entry itself to see if the entry changed at all and if not, avoid writing to the cache. === Implementation details === Details TBD, but so far we were thinking along the lines of: * using `modifyTimestamp` to detect if the entry changed at all. We would have to be smart when switching to a new server, because the new server might be out-of-sync and the timestamps might differ between replicas * using `modifyTimestamp` wouldn't work well for users, because (at least with IPA), every authentication is a write operation, due to updating the `krbLastSuccessfulAuth` attribute. Therefore, we also need to compare the cached entry's attributes wit
[SSSD] Re: [PATCH] PAM: Notify user of denial due to AD account lockout
On Fri, Feb 12, 2016 at 02:37:05PM +0100, Pavel Reichl wrote: > > > On 02/12/2016 02:19 PM, Pavel Reichl wrote: > > > > > >On 02/09/2016 04:25 PM, Pavel Reichl wrote: > >> > >> > >>On 02/09/2016 08:09 AM, Jakub Hrozek wrote: > >>>On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote: > >> > diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml > index > 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e > 100644 > --- a/src/man/sssd.conf.5.xml > +++ b/src/man/sssd.conf.5.xml > @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, > please call help desk. > > > > +pam_account_locked_message (string) > + > + > + If user is authenticating and > >>> > >>>Please ask someone for an English review (I know Dan started, but I > >>>didn't see a fixed version yet). At the very least, this should read "a > >>>user". > >> > >>I attached Dan's patch. I took the liberty of adding note regarding pam > >>verbosity. Hope it's fine by Dan. > >> > >>> > + account is locked then by default > + 'Permission denied' is output. This output > will > + be changed to content of this variable if it > is > + set. > + > + > +example: > + > +pam_account_locked_message = Account locked, please call help desk. > + > + > + > +Default: none > + > + > + > + > p11_child_timeout (integer) > > > >>> > >>>The rest of the patch looks good to me and seems to work as advertized. > >> > >>Thanks. > >> > >> > >>___ > >>sssd-devel mailing list > >>sssd-devel@lists.fedorahosted.org > >>https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org > >> > > > >Patch set with amended commit message. Commit message was acked by AB. > > > Lukas asked me for adding comment regarding documenting '775' string to the > code. Please see updated patch set. Thanks. I think we've reviewed these patches enough :) ACK CI link: http://sssd-ci.duckdns.org/logs/job/37/40/summary.html ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: [PATCH] SPEC: Remove unnecessary requirements
On (21/01/16 18:23), Lukas Slebodnik wrote:
>On (21/01/16 17:30), Sumit Bose wrote:
>>On Thu, Jan 21, 2016 at 05:09:52PM +0100, Lukas Slebodnik wrote:
>>> ehlo,
>>>
>>> reason is explained in commit message.
>>> The intention for this patch was to a simplify spec file
>>> (at least a little bit :-)
>>>
>>> If we want to have some requirements for version of lib{ldb,tdb}
>>> then it would be better to have minimal required version in
>>> BuildRequires + configure detection of libraries.
>>> But it might be outdated if we use some ver ldb features.
>>>
>>> LS
>>
>>> From 275b260be7c4365668a7adeceee6e9e089ae2f42 Mon Sep 17 00:00:00 2001
>>> From: Lukas Slebodnik
>>> Date: Thu, 21 Jan 2016 16:55:11 +0100
>>> Subject: [PATCH] SPEC: Remove unnecessary requirements
>>>
>>> We do not need to requires specific version of libldb
>>> or libtdb because it is automatically detected from
>>> binary/library dependencies. We also need never version
>>> of that libraries as it was specified in spec file.
>>>
>>> e.g.
>>> sh$ rpm -q --requires sssd-common | grep -E "TDB|LDB"
>>> libldb.so.1(LDB_0.9.10)(64bit)
>>> libtdb.so.1(TDB_1.2.1)(64bit)
>>>
>>> Our public libraries also provides version definitions
>>> therefore rpm can also detect minimal required version.
>>>
>>> sh$ rpm -q --requires sssd-common | grep -E "IDMAP"
>>> libsss_idmap.so.0(SSS_IDMAP_0.4)(64bit)
>>> sh$ $rpm -q --requires python-libsss_nss_idmap | grep -E "IDMAP"
>>> libsss_nss_idmap.so.0(SSS_NSS_IDMAP_0.0.1)(64bit)
>>> sh$ rpm -q --requires sssd-ipa | grep -E "HBAC"
>>> libipa_hbac.so.0(IPA_HBAC_0.0.1)(64bit)
>>
>>I agree with the ldb and tbd changes.
>>
>>But iirc the other explicit version dependencies should take care that
>>the sssd packages are always install with the same version. E.g. if you
>>have a system with
>>
>>libsss_nss_idmap-1.13.3-1.fc23.x86_64 and
>>python3-libsss_nss_idmap-1.13.3-1.fc23.x86_64
>>
>>installed and call
>>
>>dnf update python3-libsss_nss_idmap-1.13.3-1.fc23.x86_64
>>
>>becasue there is a newer 1.13.3-2 SSSD release, I would expect that dnf
>>only updates python3-libsss_nss_idmap to 1.13.3-2 if you remove
>>"Requires: libsss_nss_idmap = %{version}-%{release}" form the package
>>definition because the library version dependency
>>"libsss_nss_idmap.so.0(SSS_NSS_IDMAP_0.0.1)" is still satisfied by
>>libsss_nss_idmap-1.13.3-1.fc23.x86_64. As a result you have
>>
>>libsss_nss_idmap-1.13.3-1.fc23.x86_64 and
>>python3-libsss_nss_idmap-1.13.3-2.fc23.x86_64
>>
>You might looks like irritating but if you want to update just one specific
>package then it will safe a badwith and speed-up process.
>But I do not insist on the change.
>
>Meanwhile I found a redundant dependency on sssd-common-pac.
>sssd -> sssd-ipa -> sssd-common-pac
> -> sssd-ad -> sssd-common-pac
> -> sssd-common-pac
>
>I want to remove as much as possible :-)
>
>Updated version is attached.
>
>LS
>From 870eba7bfd10b726fce9162afe2484f01c4bcd90 Mon Sep 17 00:00:00 2001
>From: Lukas Slebodnik
>Date: Thu, 21 Jan 2016 16:55:11 +0100
>Subject: [PATCH] SPEC: Remove unnecessary requirements
>
>We do not need to requires specific version of libldb
>or libtdb because it is automatically detected from
>binary/library dependencies. We also need never version
>of that libraries as it was specified in spec file.
>
>e.g.
> sh$ rpm -q --requires sssd-common | grep -E "TDB|LDB"
> libldb.so.1(LDB_0.9.10)(64bit)
> libtdb.so.1(TDB_1.2.1)(64bit)
>
>There is also redundant dependency on sssd-common-pac
>sssd -> sssd-ipa -> sssd-common-pac
> -> sssd-ad -> sssd-common-pac
> -> sssd-common-pac
>
> sh$ rpm -q --whatrequires sssd-common-pac
> sssd-ipa-1.13.3-1.fc23.x86_64
> sssd-ad-1.13.3-1.fc23.x86_64
> sssd-1.13.3-1.fc23.x86_64
>---
> contrib/sssd.spec.in | 3 ---
> 1 file changed, 3 deletions(-)
BUMP
LS
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: [PATCH] Revert "DEBUG: Preventing chown_debug_file if journald on"
On (25/01/16 12:00), Lukas Slebodnik wrote: >ehlo, > >The first patch fixes regression introduced in 1.13.2. >https://fedorahosted.org/sssd/ticket/2493 > >I'm sorry I didn't catch it in review. >Fortunatelly there is a simple but annoying workaround. > >Change user to "non-root" + remove old log files. > >The second patch should fix ticket #2493 in different way. > >LS Bump. It would be good to fix a regression. a ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: [PATCH] SPEC: Remove unnecessary requirements
On Wed, Feb 17, 2016 at 01:54:56PM +0100, Lukas Slebodnik wrote:
> On (21/01/16 18:23), Lukas Slebodnik wrote:
> >On (21/01/16 17:30), Sumit Bose wrote:
> >>On Thu, Jan 21, 2016 at 05:09:52PM +0100, Lukas Slebodnik wrote:
> >>> ehlo,
> >>>
> >>> reason is explained in commit message.
> >>> The intention for this patch was to a simplify spec file
> >>> (at least a little bit :-)
> >>>
> >>> If we want to have some requirements for version of lib{ldb,tdb}
> >>> then it would be better to have minimal required version in
> >>> BuildRequires + configure detection of libraries.
> >>> But it might be outdated if we use some ver ldb features.
> >>>
> >>> LS
> >>
> >>> From 275b260be7c4365668a7adeceee6e9e089ae2f42 Mon Sep 17 00:00:00 2001
> >>> From: Lukas Slebodnik
> >>> Date: Thu, 21 Jan 2016 16:55:11 +0100
> >>> Subject: [PATCH] SPEC: Remove unnecessary requirements
> >>>
> >>> We do not need to requires specific version of libldb
> >>> or libtdb because it is automatically detected from
> >>> binary/library dependencies. We also need never version
> >>> of that libraries as it was specified in spec file.
> >>>
> >>> e.g.
> >>> sh$ rpm -q --requires sssd-common | grep -E "TDB|LDB"
> >>> libldb.so.1(LDB_0.9.10)(64bit)
> >>> libtdb.so.1(TDB_1.2.1)(64bit)
> >>>
> >>> Our public libraries also provides version definitions
> >>> therefore rpm can also detect minimal required version.
> >>>
> >>> sh$ rpm -q --requires sssd-common | grep -E "IDMAP"
> >>> libsss_idmap.so.0(SSS_IDMAP_0.4)(64bit)
> >>> sh$ $rpm -q --requires python-libsss_nss_idmap | grep -E "IDMAP"
> >>> libsss_nss_idmap.so.0(SSS_NSS_IDMAP_0.0.1)(64bit)
> >>> sh$ rpm -q --requires sssd-ipa | grep -E "HBAC"
> >>> libipa_hbac.so.0(IPA_HBAC_0.0.1)(64bit)
> >>
> >>I agree with the ldb and tbd changes.
> >>
> >>But iirc the other explicit version dependencies should take care that
> >>the sssd packages are always install with the same version. E.g. if you
> >>have a system with
> >>
> >>libsss_nss_idmap-1.13.3-1.fc23.x86_64 and
> >>python3-libsss_nss_idmap-1.13.3-1.fc23.x86_64
> >>
> >>installed and call
> >>
> >>dnf update python3-libsss_nss_idmap-1.13.3-1.fc23.x86_64
> >>
> >>becasue there is a newer 1.13.3-2 SSSD release, I would expect that dnf
> >>only updates python3-libsss_nss_idmap to 1.13.3-2 if you remove
> >>"Requires: libsss_nss_idmap = %{version}-%{release}" form the package
> >>definition because the library version dependency
> >>"libsss_nss_idmap.so.0(SSS_NSS_IDMAP_0.0.1)" is still satisfied by
> >>libsss_nss_idmap-1.13.3-1.fc23.x86_64. As a result you have
> >>
> >>libsss_nss_idmap-1.13.3-1.fc23.x86_64 and
> >>python3-libsss_nss_idmap-1.13.3-2.fc23.x86_64
> >>
> >You might looks like irritating but if you want to update just one specific
> >package then it will safe a badwith and speed-up process.
> >But I do not insist on the change.
> >
> >Meanwhile I found a redundant dependency on sssd-common-pac.
> >sssd -> sssd-ipa -> sssd-common-pac
> > -> sssd-ad -> sssd-common-pac
> > -> sssd-common-pac
> >
> >I want to remove as much as possible :-)
> >
> >Updated version is attached.
> >
> >LS
>
> >From 870eba7bfd10b726fce9162afe2484f01c4bcd90 Mon Sep 17 00:00:00 2001
> >From: Lukas Slebodnik
> >Date: Thu, 21 Jan 2016 16:55:11 +0100
> >Subject: [PATCH] SPEC: Remove unnecessary requirements
> >
> >We do not need to requires specific version of libldb
> >or libtdb because it is automatically detected from
> >binary/library dependencies. We also need never version
> >of that libraries as it was specified in spec file.
> >
> >e.g.
> > sh$ rpm -q --requires sssd-common | grep -E "TDB|LDB"
> > libldb.so.1(LDB_0.9.10)(64bit)
> > libtdb.so.1(TDB_1.2.1)(64bit)
> >
> >There is also redundant dependency on sssd-common-pac
> >sssd -> sssd-ipa -> sssd-common-pac
> > -> sssd-ad -> sssd-common-pac
> > -> sssd-common-pac
> >
> > sh$ rpm -q --whatrequires sssd-common-pac
> > sssd-ipa-1.13.3-1.fc23.x86_64
> > sssd-ad-1.13.3-1.fc23.x86_64
> > sssd-1.13.3-1.fc23.x86_64
> >---
> > contrib/sssd.spec.in | 3 ---
> > 1 file changed, 3 deletions(-)
> BUMP
ACK (sorry for the delay)
bye,
Sumit
>
> LS
> ___
> sssd-devel mailing list
> sssd-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] Re: [PATCH] PAM: Notify user of denial due to AD account lockout
On (17/02/16 13:54), Jakub Hrozek wrote: >On Fri, Feb 12, 2016 at 02:37:05PM +0100, Pavel Reichl wrote: >> >> >> On 02/12/2016 02:19 PM, Pavel Reichl wrote: >> > >> > >> >On 02/09/2016 04:25 PM, Pavel Reichl wrote: >> >> >> >> >> >>On 02/09/2016 08:09 AM, Jakub Hrozek wrote: >> >>>On Mon, Feb 08, 2016 at 01:56:07PM +0100, Pavel Reichl wrote: >> >> >> diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml >> index >> 73a21bfa0049bc4d3cfacb49201707868c87e533..2dbc58a451686beda0faa9e9366bbc3b3b4c253e >> 100644 >> --- a/src/man/sssd.conf.5.xml >> +++ b/src/man/sssd.conf.5.xml >> @@ -1040,6 +1040,27 @@ pam_account_expired_message = Account expired, >> please call help desk. >> >> >> >> +pam_account_locked_message (string) >> + >> + >> + If user is authenticating and >> >>> >> >>>Please ask someone for an English review (I know Dan started, but I >> >>>didn't see a fixed version yet). At the very least, this should read "a >> >>>user". >> >> >> >>I attached Dan's patch. I took the liberty of adding note regarding pam >> >>verbosity. Hope it's fine by Dan. >> >> >> >>> >> + account is locked then by default >> + 'Permission denied' is output. This output >> will >> + be changed to content of this variable if it >> is >> + set. >> + >> + >> +example: >> + >> +pam_account_locked_message = Account locked, please call help desk. >> + >> + >> + >> +Default: none >> + >> + >> + >> + >> p11_child_timeout (integer) >> >> >> >>> >> >>>The rest of the patch looks good to me and seems to work as advertized. >> >> >> >>Thanks. >> >> >> > >> >Patch set with amended commit message. Commit message was acked by AB. >> > >> Lukas asked me for adding comment regarding documenting '775' string to the >> code. Please see updated patch set. Thanks. > >I think we've reviewed these patches enough :) > >ACK > >CI link: http://sssd-ci.duckdns.org/logs/job/37/40/summary.html master: * 09092b6535b711b9b734ed0c047c671de9e6cafd * 4180d485829969d4626cc7d49d2b5f7146512f21 * ff275f4c0b8cc1a098dbd0c5f6d52d6a93cda597 sssd-1-13: * ffe3df61d85c2890a31d627c5e6fe8890f1e26d8 * 1b9f294dab02e6bcd4ce54e3447648d3d664ceaa * 81cb4057920c6296b7f7e6b7c651fdb601ff0338 LS ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
[SSSD] [PATCH] sss_idmap-tests: Fix segmentation fault
ehlo, simple patch is attached. I can reproduce it only with clang. But it's typical off by one error. sh$ ./sss_idmap-tests Running suite(s): IDMAP Segmentation fault (core dumped) Running suite(s): IDMAP ==2644== Process terminating with default action of signal 11 (SIGSEGV) ==2644== Access not within mapped region at address 0xA08F430 ==2644==at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) ==2644==by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices (sss_idmap-tests.c:451) ==2644==by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) ==2644==by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) ==2644==by 0x4061EE: main (sss_idmap-tests.c:965) ==2644== If you believe this happened as a result of a stack ==2644== overflow in your program's main thread (unlikely but ==2644== possible), you can try to increase the size of the ==2644== main thread stack using the --main-stacksize= flag. ==2644== The main thread stack size used in this run was 8388608. LS >From 10b1603e94a8785954f53b17f1e402b3019b29fa Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Wed, 17 Feb 2016 17:23:37 +0100 Subject: [PATCH] sss_idmap-tests: Fix segmentation fault I can reproduce it only with clang. But it's tipical off by one error. sh$ ./sss_idmap-tests Running suite(s): IDMAP Segmentation fault (core dumped) Running suite(s): IDMAP ==2644== Process terminating with default action of signal 11 (SIGSEGV) ==2644== Access not within mapped region at address 0xA08F430 ==2644==at 0x4C2CC53: strcmp (vg_replace_strmem.c:842) ==2644==by 0x4060DA: idmap_test_sid2uid_additional_secondary_slices (sss_idmap-tests.c:451) ==2644==by 0x503C78A: ??? (in /usr/lib64/libcheck.so.0.0.0) ==2644==by 0x503CB7C: srunner_run (in /usr/lib64/libcheck.so.0.0.0) ==2644==by 0x4061EE: main (sss_idmap-tests.c:965) ==2644== If you believe this happened as a result of a stack ==2644== overflow in your program's main thread (unlikely but ==2644== possible), you can try to increase the size of the ==2644== main thread stack using the --main-stacksize= flag. ==2644== The main thread stack size used in this run was 8388608. --- src/tests/sss_idmap-tests.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/tests/sss_idmap-tests.c b/src/tests/sss_idmap-tests.c index 900b7bff1cd4f3c6f9cdffc4b012864d05e72913..885913645ed286636758f3f48a5a62d87cc9ab75 100644 --- a/src/tests/sss_idmap-tests.c +++ b/src/tests/sss_idmap-tests.c @@ -427,8 +427,8 @@ START_TEST(idmap_test_sid2uid_additional_secondary_slices) struct TALLOC_CTX *tmp_ctx; const char *dom_prefix = "S-1-5-21-1-2-3"; const int max_rid = 80; -const char *sids[max_rid]; -unsigned int ids[max_rid]; +const char *sids[max_rid + 1]; +unsigned int ids[max_rid + 1]; tmp_ctx = talloc_new(NULL); fail_unless(tmp_ctx != NULL, "Out of memory."); -- 2.5.0 ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
