[SSSD] [PATCH] Remove generated manpages when performing make clean
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fixes https://fedorahosted.org/sssd/ticket/614 - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyI0zEACgkQeiVVYja6o6Ou4ACfTREyrBAGYT67DN4GeoVs/UJ0 C2IAn0la/bOEhoGXBsuPTCLBn4fH54VF =LML/ -END PGP SIGNATURE- From f0228fb0ce0b06d71bf48252ed7788d3a5342047 Mon Sep 17 00:00:00 2001 From: Stephen Gallagher sgall...@redhat.com Date: Thu, 9 Sep 2010 08:27:58 -0400 Subject: [PATCH] Remove generated manpages when performing make clean Fixes https://fedorahosted.org/sssd/ticket/614 --- Makefile.am |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index f3f5a329cf0839f4bdffe41068470c00cae26db4..10335a51bb772eddfe936697e3e0d459a9bdfdb2 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1083,6 +1083,7 @@ if BUILD_PYTHON_BINDINGS cd $(srcdir)/src/config; $(PYTHON) setup.py build --build-base $(abs_builddir)/src/config clean --all endif rm -Rf doc + rm -f $(dist_man_MANS) CLEANFILES = *.X */*.X */*/*.X -- 1.7.2.2 0001-Remove-generated-manpages-when-performing-make-clean.patch.sig Description: PGP signature ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Save all data to sysdb in one transaction
On Wed, Sep 08, 2010 at 09:52:31AM -0400, Stephen Gallagher wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/2010 09:50 AM, Sumit Bose wrote:
On Wed, Sep 08, 2010 at 09:33:04AM -0400, Stephen Gallagher wrote:
On 07/08/2010 12:57 PM, Stephen Gallagher wrote:
Just a reminder that it's been about a month since there was any
activity on this patch.
*bump* Any word on this one, Sumit? Would you prefer that I have someone
else look into this?
ah, sorry, I have a patch which addresses the comments in my tree, but I
need to rebase it. I will send it tomorrow or Friday.
Okay, no problem. If there are any further review comments at that
point, I'm going to turn it over to Jakub to finish up.
rebased versions are attached. It was necessary to add some
modifications during the rebase. I have done a couple of online and
offline test but it would be nice if someone else can run additional
tests.
bye,
Sumit
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkyHlR8ACgkQeiVVYja6o6MKkgCeNCEYKVfiOvZLl09I+zZJ7ZQ2
YAkAn2hu0LXBr3I7AIjJN9nOFWP8CTXT
=yHsK
-END PGP SIGNATURE-
From 60db9e05332137d13ca437029419630e8c52b99f Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Wed, 2 Jun 2010 11:45:24 +0200
Subject: [PATCH 1/2] Handle host objects like other objects
---
src/providers/ipa/ipa_access.c | 309 +++-
src/providers/ipa/ipa_access.h |3 +-
2 files changed, 183 insertions(+), 129 deletions(-)
diff --git a/src/providers/ipa/ipa_access.c b/src/providers/ipa/ipa_access.c
index 3fb8191..d1ba6c7 100644
--- a/src/providers/ipa/ipa_access.c
+++ b/src/providers/ipa/ipa_access.c
@@ -164,6 +164,144 @@ static errno_t hbac_sysdb_data_recv(TALLOC_CTX *mem_ctx,
return EOK;
}
+static errno_t set_local_and_remote_host_info(TALLOC_CTX *mem_ctx,
+ size_t host_count,
+ struct sysdb_attrs **host_list,
+ const char *local_hostname,
+ const char *remote_hostname,
+ struct hbac_host_info
**local_hhi,
+ struct hbac_host_info
**remote_hhi)
+
+{
+size_t c;
+int ret;
+struct hbac_host_info *hhi;
+struct ldb_message_element *el;
+TALLOC_CTX *tmp_ctx;
+
+if (local_hostname == NULL || *local_hostname == '\0') {
+DEBUG(1, (Missing local hostname.\n));
+ret = EINVAL;
+goto done;
+}
+
+if (host_count == 0) {
+DEBUG(1, (No host data available.\n));
+ret = EINVAL;
+goto done;
+}
+
+tmp_ctx = talloc_new(mem_ctx);
+if (tmp_ctx == NULL) {
+ret = ENOMEM;
+goto done;
+}
+
+for (c = 0; c host_count; c++) {
+hhi = talloc_zero(tmp_ctx, struct hbac_host_info);
+if (hhi == NULL) {
+DEBUG(1, (talloc_zero failed.\n));
+ret = ENOMEM;
+goto done;
+}
+
+ret = sysdb_attrs_get_el(host_list[c], SYSDB_ORIG_DN, el);
+if (ret != EOK) {
+DEBUG(1, (sysdb_attrs_get_el failed.\n));
+goto done;
+}
+if (el-num_values == 0) {
+DEBUG(1, (Missing OriginalDN.\n));
+ret = EINVAL;
+goto done;
+}
+DEBUG(9, (OriginalDN: [%.*s].\n, el-values[0].length,
+ (char *)el-values[0].data));
+hhi-dn = talloc_strndup(hhi, (char *)el-values[0].data,
+ el-values[0].length);
+if (hhi-dn == NULL) {
+DEBUG(1, (talloc_strndup failed.\n));
+ret = ENOMEM;
+goto done;
+}
+
+ret = sysdb_attrs_get_el(host_list[c], IPA_HOST_SERVERHOSTNAME, el);
+if (ret != EOK) {
+DEBUG(1, (sysdb_attrs_get_el failed.\n));
+goto done;
+}
+if (el-num_values == 0) {
+DEBUG(1, (Missing ServerHostName.\n));
+ret = EINVAL;
+goto done;
+}
+DEBUG(9, (ServerHostName: [%.*s].\n, el-values[0].length,
+ (char *)el-values[0].data));
+hhi-serverhostname = talloc_strndup(hhi, (char *)el-values[0].data,
+ el-values[0].length);
+if (hhi-serverhostname == NULL) {
+DEBUG(1, (talloc_strndup failed.\n));
+ret = ENOMEM;
+goto done;
+}
+
+ret = sysdb_attrs_get_el(host_list[c], IPA_HOST_FQDN, el);
+if (ret != EOK) {
+
[SSSD] [PATCH] Fix parameter order when initializing decryption
I made a stupid error in the decryption code which caused the decryption
to fail on i686. Sumit found the bug out and the attached patch fixes it.
From d5934e29143db5d772da720b6789324dad9a05b3 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek jhro...@redhat.com
Date: Thu, 9 Sep 2010 15:06:21 +0200
Subject: [PATCH] Fix parameter order when initializing decryption
---
src/util/crypto/nss/nss_obfuscate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/util/crypto/nss/nss_obfuscate.c b/src/util/crypto/nss/nss_obfuscate.c
index 69dbbf3..1c6eb1d 100644
--- a/src/util/crypto/nss/nss_obfuscate.c
+++ b/src/util/crypto/nss/nss_obfuscate.c
@@ -272,7 +272,7 @@ int sss_password_encrypt(TALLOC_CTX *mem_ctx, const char *password, int plen,
}
ret = nss_encrypt_decrypt_init(tmp_ctx, mech_props, true,
- keybuf, ivbuf, cctx);
+ ivbuf, keybuf, cctx);
if (ret) {
goto done;
}
--
1.7.2.2
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] Behaviour of getgrnam/getgrgid
Hi,
Is it really the intended behaviour of the sssd LDAP backend (I am
running the current code from the master branch) to only return the group
members that are already cached in sysdb and to silently ignore
everything else? E.g. when I start sssd with empty caches and do a
getent group random-ldap-group I will only get back the group without
any members. Somehow I think this can't be intended :)
I have started working on a patch to let sssd look up the non-cached
users via LDAP (and save them into the cache). Find it attached. Note:
That patch is not really complete (e.g. it doesn't handle rfc2307 groups
correctly). But before putting more effort into this I like to make sure
that I am not trying to fix a feature here.
--
regards,
Ralf
From 063dab6715f97aeeb6c29f5c3210f609cfea0f81 Mon Sep 17 00:00:00 2001
From: Ralf Haferkamp rha...@suse.de
Date: Wed, 8 Sep 2010 10:30:03 +0200
Subject: [PATCH] Return all group members from getgr(nam|gid)
getgrnam()/getgrgid() should return all group members instead of only those
which have already been cached (in sysdb). To achieve this every member
that is currently not in the cache is looked up via LDAP and saved to the
cache.
---
src/providers/ldap/sdap_async_accounts.c | 177 --
1 files changed, 169 insertions(+), 8 deletions(-)
diff --git a/src/providers/ldap/sdap_async_accounts.c b/src/providers/ldap/sdap_async_accounts.c
index 8999ba0..795c7ca 100644
--- a/src/providers/ldap/sdap_async_accounts.c
+++ b/src/providers/ldap/sdap_async_accounts.c
@@ -4,6 +4,7 @@
Async LDAP Helper routines
Copyright (C) Simo Sorce sso...@redhat.com - 2009
+Copyright (C) 2010, Ralf Haferkamp rha...@suse.de, Novell Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -917,6 +918,20 @@ struct sdap_get_groups_state {
char *higher_timestamp;
struct sysdb_attrs **groups;
size_t count;
+size_t check_count;
+};
+
+struct sdap_process_group_state {
+struct tevent_context *ev;
+struct sdap_options *opts;
+struct sdap_handle *sh;
+struct sss_domain_info *dom;
+struct sysdb_ctx *sysdb;
+
+struct sysdb_attrs *group;
+struct sysdb_attrs **new_members;
+size_t count;
+size_t check_count;
};
static void sdap_get_groups_process(struct tevent_req *subreq);
@@ -962,13 +977,22 @@ struct tevent_req *sdap_get_groups_send(TALLOC_CTX *memctx,
return req;
}
+static void sdap_groupmember_process(struct tevent_req *subreq);
+static void sdap_group_process(struct tevent_req *subreq);
+
static void sdap_get_groups_process(struct tevent_req *subreq)
{
struct tevent_req *req = tevent_req_callback_data(subreq,
struct tevent_req);
struct sdap_get_groups_state *state = tevent_req_data(req,
struct sdap_get_groups_state);
-int ret;
+struct tevent_req *process_member_req;
+struct tevent_req *process_grp_req;
+struct ldb_message_element *el;
+struct sdap_process_group_state *grp_state;
+const char **attrs;
+char *filter;
+int ret,i,k;
ret = sdap_get_generic_recv(subreq, state,
state-count, state-groups);
@@ -985,19 +1009,156 @@ static void sdap_get_groups_process(struct tevent_req *subreq)
return;
}
-ret = sdap_save_groups(state, state-sysdb,
- state-dom, state-opts,
- state-groups, state-count,
- state-higher_timestamp);
+state-check_count = state-count;
+
+ret = build_attrs_from_map(state, state-opts-user_map, SDAP_OPTS_USER,
+ attrs);
+filter = talloc_asprintf(state, (objectclass=%s),
+ state-opts-user_map[SDAP_OC_USER].name);
+
+for (i=0; i state-count; i++) {
+ret = sysdb_attrs_get_el(state-groups[i],
+state-opts-group_map[SDAP_AT_GROUP_NAME].sys_name, el);
+if (ret || el-num_values == 0) {
+tevent_req_error(req, ENOENT);
+return;
+}
+
+DEBUG(2, (Processing Group %s\n, (const char*)el-values[0].data));
+process_grp_req = tevent_req_create(state, grp_state,
+struct sdap_process_group_state);
+if (!process_grp_req) {
+tevent_req_error(req, ENOMEM);
+return;
+}
+
+grp_state-ev = state-ev;
+grp_state-opts = state-opts;
+grp_state-dom = state-dom;
+grp_state-sh = state-sh;
+grp_state-sysdb = state-sysdb;
+grp_state-group = state-groups[i];
+grp_state-check_count = 0;
+grp_state-new_members = NULL;
+tevent_req_set_callback(process_grp_req, sdap_group_process, req);
+
+ret =
Re: [SSSD] Behaviour of getgrnam/getgrgid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. I'll take a look at this patch soon, but I can't promise that I'll get to it this week (I'm a bit swamped). - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyI3pQACgkQeiVVYja6o6O8CQCfUwXPg7yy7iqfN2R4oz1C6Hqe 3J8AoKy/Y0CU3IyfaNEQjLIEwJ3LNX7H =1yoq -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thu, 09 Sep 2010 09:18:12 -0400 Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. It is intended if enumerations are off. Thee reason is that you may end up effectively doing full user enumerations otherwise if you have a big group that contain all users. Not only that but it would be an inefficient enumeration as it would be repeated multiple times for each group. And if you have a *lot* of users this would defeat the point of disabling enumerations, making performances actually worse. So please do not change this without proper discussion. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thursday 09 September 2010 15:59:46 Simo Sorce wrote: On Thu, 09 Sep 2010 09:18:12 -0400 Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. It is intended if enumerations are off. Thee reason is that you may end up effectively doing full user enumerations otherwise if you have a big group that contain all users. Then it should probably be possible to disable that feature separately from enumeration. While, turning enumerations off by default makes sense to me, I think returning incomplete results when resolving groups by default goes a bit too far. BTW, I just found out that the behaviour of getgrouplist()/initgroups() is similar currently. It will only return the groups that are already present in the cache. That means in many cases it will return nothing. (Or just the gid you supplied via the group argument). Not only that but it would be an inefficient enumeration as it would be repeated multiple times for each group. Why is that? Users should of course be saved in the sysdb after being read from LDAP. If you read another group which has that user as a member the result is taken from the cache of course. (That's what my patch tries to do at least, though I admit there is still room for optimization) And if you have a *lot* of users this would defeat the point of disabling enumerations, making performances actually worse. So please do not change this without proper discussion. regards, Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thu, 9 Sep 2010 16:46:35 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 15:59:46 Simo Sorce wrote: On Thu, 09 Sep 2010 09:18:12 -0400 Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. It is intended if enumerations are off. Thee reason is that you may end up effectively doing full user enumerations otherwise if you have a big group that contain all users. Then it should probably be possible to disable that feature separately from enumeration. While, turning enumerations off by default makes sense to me, I think returning incomplete results when resolving groups by default goes a bit too far. It depends on the point of view. For the specific logged in user the groups he is interested in are fully update wrt his own membership. It is true you may not see other members unless they log in, but why would that be a problem ? If they do not log in they are not affected by group memberships anyway. BTW, I just found out that the behaviour of getgrouplist()/initgroups() is similar currently. It will only return the groups that are already present in the cache. That means in many cases it will return nothing. (Or just the gid you supplied via the group argument). Initgroups will always call the LDAP server, and will make sure all groups the user is member of are available. Not only that but it would be an inefficient enumeration as it would be repeated multiple times for each group. Why is that? Users should of course be saved in the sysdb after being read from LDAP. If you read another group which has that user as a member the result is taken from the cache of course. (That's what my patch tries to do at least, though I admit there is still room for optimization) In order to save a user you have to look it up. so if you have a group with 50k users in it you will have to do 50k lookups. Multiply this for N groups. If you need enumeration completeness then you should just have enumerations turned on IMO. Now thinking a bit more there is probably a way to avoid the lookups. You can avoid the 50k lookups by actually *not* fetching each member from LDAP but create fake entries that are marked as expired so they are immediately refreshed with the right data if they are ever requested from the user space. But this technique has some pretty sever limits when using rfc2307bis and nested groups. (should work just fine for classic rfc2307) One limit is that you don't know whether a DN is a user or a Group. It is true that we can adopt some heuristics like examining the DN components to get a clue, but they would be pretty much schema dependent and would fail consistently in some scenarios. So you may fail to properly unroll nested groups. The other is that the actual user name may not be contained within the DN. if the DN includes the uid attribute as part of it does, but if the CN is used (like against AD where the samAccoutnName attribute is used as the OS user name) then you do not have the user name you need to present in the group as member. So, again, it would work only in some setups. Another concern is about how to properly do caching. When we did the initgroups call I used to fully resolve groups, we removed that code because it would make initgroups unbearably slow as it would end up doing way too many lookups. So we need to make sure initgroups can create/manipulate groups and know when a group can be considered up to date, and yet at the same time mark it as incomplete or something like that for getent group group calls (and vice versa ?) I guess we could have a third option to manage this, and allow people full group (all member users/groups(recursive)) lookups if they really want/need it. But it has a lot of subtle interactions we need to care about to avoid perf. side effects. May be something like: fully_resolve_groups defaulting to false ? Simo. -- Simo Sorce * Red Hat, Inc * New York
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thu, Sep 9, 2010 at 8:48 AM, Simo Sorce sso...@redhat.com wrote: On Thu, 9 Sep 2010 16:46:35 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 15:59:46 Simo Sorce wrote: On Thu, 09 Sep 2010 09:18:12 -0400 Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. It is intended if enumerations are off. Thee reason is that you may end up effectively doing full user enumerations otherwise if you have a big group that contain all users. Then it should probably be possible to disable that feature separately from enumeration. While, turning enumerations off by default makes sense to me, I think returning incomplete results when resolving groups by default goes a bit too far. It depends on the point of view. For the specific logged in user the groups he is interested in are fully update wrt his own membership. It is true you may not see other members unless they log in, but why would that be a problem ? If they do not log in they are not affected by group memberships anyway. BTW, I just found out that the behaviour of getgrouplist()/initgroups() is similar currently. It will only return the groups that are already present in the cache. That means in many cases it will return nothing. (Or just the gid you supplied via the group argument). Initgroups will always call the LDAP server, and will make sure all groups the user is member of are available. Not only that but it would be an inefficient enumeration as it would be repeated multiple times for each group. Why is that? Users should of course be saved in the sysdb after being read from LDAP. If you read another group which has that user as a member the result is taken from the cache of course. (That's what my patch tries to do at least, though I admit there is still room for optimization) In order to save a user you have to look it up. so if you have a group with 50k users in it you will have to do 50k lookups. Multiply this for N groups. If you need enumeration completeness then you should just have enumerations turned on IMO. Now thinking a bit more there is probably a way to avoid the lookups. You can avoid the 50k lookups by actually *not* fetching each member from LDAP but create fake entries that are marked as expired so they are immediately refreshed with the right data if they are ever requested from the user space. But this technique has some pretty sever limits when using rfc2307bis and nested groups. (should work just fine for classic rfc2307) One limit is that you don't know whether a DN is a user or a Group. It is true that we can adopt some heuristics like examining the DN components to get a clue, but they would be pretty much schema dependent and would fail consistently in some scenarios. So you may fail to properly unroll nested groups. The other is that the actual user name may not be contained within the DN. if the DN includes the uid attribute as part of it does, but if the CN is used (like against AD where the samAccoutnName attribute is used as the OS user name) then you do not have the user name you need to present in the group as member. So, again, it would work only in some setups. Another concern is about how to properly do caching. When we did the initgroups call I used to fully resolve groups, we removed that code because it would make initgroups unbearably slow as it would end up doing way too many lookups. So we need to make sure initgroups can create/manipulate groups and know when a group can be considered up to date, and yet at the same time mark it as incomplete or something like that for getent group group calls (and vice versa ?) I guess we could have a third option to manage this, and allow people full group (all member users/groups(recursive)) lookups if they really want/need it. But it has a lot of subtle interactions we need to care about to avoid perf. side effects. May be something like:
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Thu, 9 Sep 2010 08:57:37 -0700 Jeff Schroeder jeffschroe...@computer.org wrote: On Thu, Sep 9, 2010 at 8:48 AM, Simo Sorce sso...@redhat.com wrote: On Thu, 9 Sep 2010 16:46:35 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 15:59:46 Simo Sorce wrote: On Thu, 09 Sep 2010 09:18:12 -0400 Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/2010 09:14 AM, Ralf Haferkamp wrote: Hi, Is it really the intended behaviour of the sssd LDAP backend (I am running the current code from the master branch) to only return the group members that are already cached in sysdb and to silently ignore everything else? E.g. when I start sssd with empty caches and do a getent group random-ldap-group I will only get back the group without any members. Somehow I think this can't be intended :) I have started working on a patch to let sssd look up the non-cached users via LDAP (and save them into the cache). Find it attached. Note: That patch is not really complete (e.g. it doesn't handle rfc2307 groups correctly). But before putting more effort into this I like to make sure that I am not trying to fix a feature here. No, it is not intentional that groups should be missing users. This is definitely a bug. Please file a ticket upstream. It is intended if enumerations are off. Thee reason is that you may end up effectively doing full user enumerations otherwise if you have a big group that contain all users. Then it should probably be possible to disable that feature separately from enumeration. While, turning enumerations off by default makes sense to me, I think returning incomplete results when resolving groups by default goes a bit too far. It depends on the point of view. For the specific logged in user the groups he is interested in are fully update wrt his own membership. It is true you may not see other members unless they log in, but why would that be a problem ? If they do not log in they are not affected by group memberships anyway. BTW, I just found out that the behaviour of getgrouplist()/initgroups() is similar currently. It will only return the groups that are already present in the cache. That means in many cases it will return nothing. (Or just the gid you supplied via the group argument). Initgroups will always call the LDAP server, and will make sure all groups the user is member of are available. Not only that but it would be an inefficient enumeration as it would be repeated multiple times for each group. Why is that? Users should of course be saved in the sysdb after being read from LDAP. If you read another group which has that user as a member the result is taken from the cache of course. (That's what my patch tries to do at least, though I admit there is still room for optimization) In order to save a user you have to look it up. so if you have a group with 50k users in it you will have to do 50k lookups. Multiply this for N groups. If you need enumeration completeness then you should just have enumerations turned on IMO. Now thinking a bit more there is probably a way to avoid the lookups. You can avoid the 50k lookups by actually *not* fetching each member from LDAP but create fake entries that are marked as expired so they are immediately refreshed with the right data if they are ever requested from the user space. But this technique has some pretty sever limits when using rfc2307bis and nested groups. (should work just fine for classic rfc2307) One limit is that you don't know whether a DN is a user or a Group. It is true that we can adopt some heuristics like examining the DN components to get a clue, but they would be pretty much schema dependent and would fail consistently in some scenarios. So you may fail to properly unroll nested groups. The other is that the actual user name may not be contained within the DN. if the DN includes the uid attribute as part of it does, but if the CN is used (like against AD where the samAccoutnName attribute is used as the OS user name) then you do not have the user name you need to present in the group as member. So, again, it would work only in some setups. Another concern is about how to properly do caching. When we did the initgroups call I used to fully resolve groups, we removed that code because it would make initgroups unbearably slow as it would end up doing way too many lookups. So we need to make sure initgroups can create/manipulate groups and know when a group can be considered up to date, and yet at the same time mark it as incomplete or something like that for getent group group calls (and vice versa ?) I guess we could have a third option to manage this, and allow people full group (all member
Re: [SSSD] Netgroups in SSSD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/08/2010 09:04 AM, Stephen Gallagher wrote: I've also been thinking about how we're going to handle processing the nested groups, and I think what I'm going to do is take advantage of some of the nicer features of libcollection. Internal processing of setnetgrent_send() will recursively call out a subrequest to setnetgrent_send() again for each of the named nested groups. The setnetgrent_recv() function will return a libcollection object containing all of the results from that request (as well as any additional subrequests called). When the results come back up, they can be added together trivially using the col_add_collection_to_collection() interface with the col_add_mode_clone mode. I've added some additional details about how I would like to do the nesting and loop detection to the wiki page. Comments welcome. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJEvYACgkQeiVVYja6o6PsBQCePVgQm9TVj3aSCPKkGL+h2DS6 1u4AoIAvj2c0Mt7bCeMYkMwEExLtiPWU =kdvv -END PGP SIGNATURE- ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
