Re: [SSSD] Behaviour of getgrnam/getgrgid
On Fri, 10 Sep 2010 12:06:25 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 18:33:26 Simo Sorce wrote: So we have the following scenarios: 1) If we use rfc2307 classic with memberUid attributes, we can just create the fake/expired users and be done with it. Agreed. 2) If we use rfc2307bis w/o nested groups we can count the number of members on the group entry and switch to a full user enumeration if the number of members is greater than a defined (potentially user defined) threshold. Assuming a threshold value of 100, if we have 10 members we just do 10 lookups, while, if we have 100 member we do a full enumeration (it's a single ldap search, and if modifyTimestamp is used also highly optimized after the first search) so we are sure all users are there with the right name. I think that's an optimization that could be worth exploring later. In a first iteration I'd just go for implementing the complete group lookup by looking up every single user regardless of how large the group is. (plus the possiblity to completely disable member unrolling through the configuration) Ok, although performances will suck so much I bet we will have to implement the optimization pretty soon. 3) If we use rfc2307bis with nested groups we do the same as in 2, but we add an internal user lookup against the cache we just populated to determine if some members are groups that need further lookups in order to complete the group unrolling operation. Why do an extra cache lookup? You could issue the addtional LDAP lookups right when you receive the entries of the group members. Provided the correct LDAP attributes where requested (i.e. user attributes + groups attributes). True, it is necessary only when you use the optimization of doing one search for all users. When you lookup each entry individually you just need to keep a list of groups to further search, and simply repeat the operation for each of those groups (need to set a limit to recursion). 4) If we use IPA (rfc2307bis + nested groups + unrolled members in memberOf attribute), we can do a single search with memberOf=groupDN, as IPa's memberOf fully resolves nested groups. This would return all and only the users members of the group. So if the group has 101 members in a directory of 50k users we do not do a full 50k users enumeration just because we have a group that is 1 above the threshold. Do I miss any scenario ? Simo. 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 Fri, 10 Sep 2010 11:31:48 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 17:48:09 Simo Sorce wrote: On Thu, 9 Sep 2010 16:46:35 +0200 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. The user currently logged in might need to see who else is member of the groups he is member of. Ok, I know of no application that needs it, but if users request it its enough. 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. Ok, there something else seems broken here: 1. When initgroups is called for a user that is currently not cached no LDAP groups are returned. (I guess that's inline with your idea about how sssd should behave) No, initgroups should always fetch the user's groups, please open a bug. 2. When the user is already cached and rfc2307bis+memberof is used on the Serverside, nothing is returned upon the first initgroups call, but the cache is correctly populated with the groups, a second initgroups call then returns the correct results. So I guess there's a bug here somewhere. Haven't investigated this deeper yet. Yes, and is probably connected with the above issue. 3. When using rfc2307 or rfc2307bis (without memberof Attributes) initgroups() seems completely broken. Sigh, please open bug I'll create bug reports after I was able to take a deeper look. (It seems some of the issues are already reported. See e.g. https://fedorahosted.org/sssd/ticket/595) Thank you. 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. Users that were already looked up when looking up the first group will not be looked up again (they are already cached) when resolving the second group. If the groups really have 50k distinct members you are of course right that a lot of LDAP lookups will need to be done. But I wonder how common such a scenario is and if sssd's default configuration should be optimized for such a usecases. I'd guess most enviroments that sssd operates in are much smaller. And there you'll confuse the users/admins when groups show up incomplete. SSSD was initially born as IPA's client. In IPA (at least in v1) every user you create is automatically made member of the ipausers groups. So that group always is as big as the whole userbase ... 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. Right, this how I was thinking about implementing it for rfc2307 groups, but I haven't come to that yet. 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. I think it is not worth to go that path for rfc2307bis groups. It wrong to rely too much on such specific setups. Yes, I am not really suggesting we do that, but I thought it was important to explain limitations in this area. 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. Agreed. For initgroups the groups should not be completely resolved. OTOH when dealing with nested groups (in a scenario without memberof) you'd have to look up all group members anyways. (IMO a reason why nested groups should be disabled by default when using a standard rfc2307bis setup.) Yes, a good reason. We should probably have a
Re: [SSSD] Behaviour of getgrnam/getgrgid
Simo Sorce wrote: On Fri, 10 Sep 2010 11:31:48 +0200 Ralf Haferkamp rha...@suse.de wrote: On Thursday 09 September 2010 17:48:09 Simo Sorce wrote: On Thu, 9 Sep 2010 16:46:35 +0200 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. The user currently logged in might need to see who else is member of the groups he is member of. Ok, I know of no application that needs it, but if users request it its enough. 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. Ok, there something else seems broken here: 1. When initgroups is called for a user that is currently not cached no LDAP groups are returned. (I guess that's inline with your idea about how sssd should behave) No, initgroups should always fetch the user's groups, please open a bug. 2. When the user is already cached and rfc2307bis+memberof is used on the Serverside, nothing is returned upon the first initgroups call, but the cache is correctly populated with the groups, a second initgroups call then returns the correct results. So I guess there's a bug here somewhere. Haven't investigated this deeper yet. Yes, and is probably connected with the above issue. 3. When using rfc2307 or rfc2307bis (without memberof Attributes) initgroups() seems completely broken. Sigh, please open bug I'll create bug reports after I was able to take a deeper look. (It seems some of the issues are already reported. See e.g. https://fedorahosted.org/sssd/ticket/595) Thank you. 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. Users that were already looked up when looking up the first group will not be looked up again (they are already cached) when resolving the second group. If the groups really have 50k distinct members you are of course right that a lot of LDAP lookups will need to be done. But I wonder how common such a scenario is and if sssd's default configuration should be optimized for such a usecases. I'd guess most enviroments that sssd operates in are much smaller. And there you'll confuse the users/admins when groups show up incomplete. SSSD was initially born as IPA's client. In IPA (at least in v1) every user you create is automatically made member of the ipausers groups. So that group always is as big as the whole userbase ... 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. Right, this how I was thinking about implementing it for rfc2307 groups, but I haven't come to that yet. 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. I think it is not worth to go that path for rfc2307bis groups. It wrong to rely too much on such specific setups. Yes, I am not really suggesting we do that, but I thought it was important to explain limitations in this area. 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. Agreed. For initgroups the groups should not be completely resolved. OTOH when dealing with nested groups (in a scenario without memberof) you'd have to look up all group members anyways. (IMO a
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Fri, 10 Sep 2010 09:06:29 -0400 Dmitri Pal d...@redhat.com wrote: Is this the right summary: 1a) Initgroups do not fetch groups from LDAP - bug I am not sure this is correct. It normally works (we have tests) but it may not work properly in some conditions. Ralf can you open a bug with logs and all ? 1b) When the user is already cached and rfc2307bis+memberof is used on the Serverside, nothing is returned upon the first initgroups call (bug above), but the cache is correctly populated with the groups, a second initgroups call then returns the correct results (task to test related to the bug above). I never seen this myself, but I haven't tested the code lately either, I'll let Ralf comment as he is the one seeing it. 2) When using rfc2307 or rfc2307bis (without memberof Attributes) initgroups() seems completely broken. (this is probably related to ticket 595) Yeah maybe just add note to 595 if necessary. 3) Have a config option to enable/disable nested groups rolling with default enabled. We should document the scenarios when it makes sense to enable or disable it. We actually proposed 2 different options in the mail thread. Option 1. Fetch/Do not fetch, all group members (default disabled) Option 2. Resolve Nested Groups, here I think the default should depend on what the server offers. If it is IPA with its memberof we can always properly resolve nested groups with almost no effort, so we should have nested groups enable by default as we encourage using them in the server. For other servers I am not sure what is the best default. In general having it on by default is not a bad idea, unless the server has been managed so badly that nesting causes issues. Another way would be to make this a property of the schema you choose, and differentiate between rfc2307bis and rfc2307bis+nested groups by having a different name. 4) Add marking to the objects. Complete mark is put on the user object when all groups he is a member of are fetched. The groups that were fetched and were not in the cache are marked as incomplete. This is only on initgroups calls, and I think the first part (properly marking the user) is already implemented, we only need to mark the groups differently. When the group members are enumerated for a group all users for a group should be fetched and group should be marked as complete, users fetched by this lookup that were not in the cache are marked as incomplete. I think we could manage by simply marking users as expired, although this may cause issues if we go offline, as we do not have uid/gid and other fields ... probably we can simply leave those fields off, and this will automatically make them incomplete. We would have to make sure the rest of the code can cope (and filter out) these users when we are offline. In the implementation there is probably no difference between the case when entry does not exist or or has incomplete status. Indeed, incomplete entries need to be revalidated (if online) or just filtered (when offline). In both cases same action needs to be taken. In both cases we need to fetch an entry. So I guess we really need just the complete mark. The difference is between the online and the offline case, but in the end yes, the complete mark is what will validate the entry for use. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
[SSSD] [PATCH] Use new MIT krb5 API for better password expiration warnings
Hi,
currently we can only present a warning message which in generated
inside the MIT Kerberos library to the user if the password is about to
expire. But the developers of MIT Kerberos were so nice to add a new API
to retrieve the original timestamps
(http://k5wiki.kerberos.org/wiki/Projects/Password_expiration_API). It
is currently available in the daily development snapshots of MIT
Kerberos and should find its way into the 1.9 release.
The attached patch checks if the new API is available and adds a
callback to read the password expiration timestamp. As mentioned on the
web page there is a small chance that this patch will not display the
time when the password expires, but the time when the account expires. I
think we can neglect this case.
bye,
Sumit
From af82ea6bbcf7accb7d4b6d9290a776595acdd1ae Mon Sep 17 00:00:00 2001
From: Sumit Bose sb...@redhat.com
Date: Fri, 10 Sep 2010 14:53:50 +0200
Subject: [PATCH] Use new MIT krb5 API for better password expiration warnings
---
src/external/krb5.m4|3 +-
src/providers/krb5/krb5_child.c | 51 +++
src/util/sss_krb5.c | 15 ++-
src/util/sss_krb5.h | 13 +-
4 files changed, 79 insertions(+), 3 deletions(-)
diff --git a/src/external/krb5.m4 b/src/external/krb5.m4
index 39c2cdf..d4f563f 100644
--- a/src/external/krb5.m4
+++ b/src/external/krb5.m4
@@ -38,7 +38,8 @@ CFLAGS=$CFLAGS $KRB5_CFLAGS
LIBS=$LIBS $KRB5_LIBS
AC_CHECK_HEADERS([krb5.h krb5/krb5.h])
AC_CHECK_FUNCS([krb5_get_init_creds_opt_alloc krb5_get_error_message \
-krb5_free_unparsed_name])
+krb5_free_unparsed_name \
+krb5_get_init_creds_opt_set_expire_callback])
CFLAGS=$SAVE_CFLAGS
LIBS=$SAVE_LIBS
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c
index 6892c66..b028962 100644
--- a/src/providers/krb5/krb5_child.c
+++ b/src/providers/krb5/krb5_child.c
@@ -104,6 +104,43 @@ static const char *__krb5_error_msg;
sss_krb5_free_error_message(krb5_error_ctx, __krb5_error_msg); \
} while(0);
+static void sss_krb5_expire_callback_func(krb5_context context, void *data,
+ krb5_timestamp password_expiration,
+ krb5_timestamp account_expiration,
+ krb5_boolean is_last_req)
+{
+int ret;
+uint32_t *blob;
+long exp_time;
+struct krb5_req *kr = talloc_get_type(data, struct krb5_req);
+
+if (password_expiration == 0) {
+return;
+}
+
+exp_time = password_expiration - time(NULL);
+if (exp_time 0 || exp_time UINT32_MAX) {
+DEBUG(1, (Time to expire out of range.\n));
+return;
+}
+
+blob = talloc_array(kr-pd, uint32_t, 2);
+if (blob == NULL) {
+DEBUG(1, (talloc_size failed.\n));
+return;
+}
+
+blob[0] = SSS_PAM_USER_INFO_EXPIRE_WARN;
+blob[1] = (uint32_t) exp_time;
+
+ret = pam_add_response(kr-pd, SSS_PAM_USER_INFO, 2 * sizeof(uint32_t),
+ (uint8_t *) blob);
+if (ret != EOK) {
+DEBUG(1, (pam_add_response failed.\n));
+}
+
+return;
+}
static krb5_error_code sss_krb5_prompter(krb5_context context, void *data,
const char *name, const char *banner,
@@ -516,6 +553,13 @@ static krb5_error_code get_and_save_tgt(struct krb5_req
*kr,
krb5_error_code kerr = 0;
int ret;
+kerr = sss_krb5_get_init_creds_opt_set_expire_callback(kr-ctx,
kr-options,
+
sss_krb5_expire_callback_func,
+ kr);
+if (kerr != 0) {
+KRB5_DEBUG(1, kerr);
+DEBUG(1, (Failed to set expire callback, continue without.\n));
+}
kerr = krb5_get_init_creds_password(kr-ctx, kr-creds, kr-princ,
password, sss_krb5_prompter, kr, 0,
NULL, kr-options);
@@ -737,6 +781,13 @@ static errno_t tgt_req_child(int fd, struct krb5_req *kr)
not. In general the password can still be used to get a changepw ticket.
So we validate the password by trying to get a changepw ticket. */
if (kerr == KRB5KDC_ERR_KEY_EXP) {
+kerr = sss_krb5_get_init_creds_opt_set_expire_callback(kr-ctx,
+ kr-options,
+ NULL, NULL);
+if (kerr != 0) {
+KRB5_DEBUG(1, kerr);
+DEBUG(1, (Failed to unset expire callback, continue ...\n));
+}
kerr = krb5_get_init_creds_password(kr-ctx, kr-creds, kr-princ,
pass_str, sss_krb5_prompter, kr, 0,
changepw_princ,
diff --git a/src/util/sss_krb5.c b/src/util/sss_krb5.c
index
Re: [SSSD] Netgroups in SSSD
Stephen Gallagher wrote: 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. Sorry I am having trouble understanding this algorithm. But may be it is because i do not understand the tevent_req interface to the level needed here. AFAIU the struct tevent_req setnetgrent_send(char *netgroupname, hash_table_t *nesting) call will ask for the netgroups, while another call errno_t setnetgrent_recv(tevent_req *req, struct collection **entries) is the call that will be executed when the response from the server is received. The problems I have are with the item 4). If it removes the netgroup from the hash how the hash ever grows? It should grow when the requests and responses (!) are processed in a nested way. But I do not think that this is possible with the interface we have (at least how it is described). If the request for a netgroup sent and then the response is received and we are processing a response and find that the netgroup has nested netgroups what do we do? Issue another request for the nested group? Fine but then we continue with the processing of the parent group and would delete it from the hash table before the result for the nested group gets back. My point is that hash table should probably be created per setnetgrent call and cleaned when fetching of all nested netgroups is complete. It should be never cleaned in the middle. Am I missing something? Also there is not design for the int innetgr(const char *netgroup, const char *host, const char *user, const char *domain); Is this intentional or just an omission? Also I think we should have the following optimization: Each fetched netgroup goes to the cache with a timestamp. If the expiration is say 30 sec and there is a netgroup C nested into two independent netgroups A and B and A is fetched and then B is fetched before the expiration timeout of the C, then the netgroup C should be taken from the cache rather than refetched. Another thing that I just realized is that you create a flat result set collection by appending nested groups rather than creating a collection with tree structure and iterating it as a flat collection. While your approach is probably the right one I wanted to draw attention to the fact that the option of having a tree style collection with nested referenced (or copied) subcollections and then traversing the tree as if it is a flat collection is also available. I do not know if you looked at such structure and whether it would help better if we need to do some optimization (now or later). Just something to consider. Thanks Dmitri ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Check for controls before using them
On 09/10/2010 11:16 AM, Sumit Bose wrote:
rebased versions attached.
bye,
Sumit
Ack to both patches, but may I suggest that the attached patch be
squashed in? Perhaps it would make for a little more readable code.
From 0f1ec31ab542f914867da1c3e94dd1e9e4aa7ad9 Mon Sep 17 00:00:00 2001
From: Jakub Hrozek jhro...@redhat.com
Date: Fri, 10 Sep 2010 17:00:40 +0200
Subject: [PATCH] Two suggestions
---
src/providers/ldap/sdap.c |6 ++
src/providers/ldap/sdap_async_connection.c |7 +--
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/src/providers/ldap/sdap.c b/src/providers/ldap/sdap.c
index 370ffde..4d911c4 100644
--- a/src/providers/ldap/sdap.c
+++ b/src/providers/ldap/sdap.c
@@ -383,16 +383,14 @@ int sdap_set_rootdse_supported_lists(struct sysdb_attrs *rootdse,
if (ret) {
return ret;
}
-}
-if (strcasecmp(el-name, supportedExtension) == 0) {
+} else if (strcasecmp(el-name, supportedExtension) == 0) {
ret = sdap_init_sup_list(sh, sh-supported_extensions,
el-num_values, el-values);
if (ret) {
return ret;
}
-}
-if (strcasecmp(el-name, supportedSASLMechanisms) == 0) {
+} else if (strcasecmp(el-name, supportedSASLMechanisms) == 0) {
ret = sdap_init_sup_list(sh, sh-supported_saslmechs,
el-num_values, el-values);
diff --git a/src/providers/ldap/sdap_async_connection.c b/src/providers/ldap/sdap_async_connection.c
index f5c6511..4c1deaf 100644
--- a/src/providers/ldap/sdap_async_connection.c
+++ b/src/providers/ldap/sdap_async_connection.c
@@ -977,12 +977,7 @@ struct tevent_req *sdap_cli_connect_send(TALLOC_CTX *memctx,
state-be = be;
state-srv = NULL;
state-be = be;
-
-if (skip_rootdse) {
-state-use_rootdse = false;
-} else {
-state-use_rootdse = true;
-}
+state-use_rootdse = !skip_rootdse;
ret = sdap_cli_resolve_next(req);
if (ret) {
--
1.7.2.2
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] Behaviour of getgrnam/getgrgid
On Friday 10 September 2010 15:34:22 Simo Sorce wrote: On Fri, 10 Sep 2010 09:06:29 -0400 Dmitri Pal d...@redhat.com wrote: Is this the right summary: 1a) Initgroups do not fetch groups from LDAP - bug I am not sure this is correct. It normally works (we have tests) but it may not work properly in some conditions. Does you testcases probably call getpwnam() before calling initgroups/getgrouplist()? Ralf can you open a bug with logs and all ? This is now #620. 1b) When the user is already cached and rfc2307bis+memberof is used on the Serverside, nothing is returned upon the first initgroups call (bug above), but the cache is correctly populated with the groups, a second initgroups call then returns the correct results (task to test related to the bug above). I never seen this myself, but I haven't tested the code lately either, I'll let Ralf comment as he is the one seeing it. I created #621 for this. 2) When using rfc2307 or rfc2307bis (without memberof Attributes) initgroups() seems completely broken. (this is probably related to ticket 595) Yeah maybe just add note to 595 if necessary. The rfc2307bis issue is #595, yes. sssd just assumes that memberof is in place when rfc2307bis is configured. It seems that the rfc2307 problem is something different though. I created #622 for that. 3) Have a config option to enable/disable nested groups rolling with default enabled. We should document the scenarios when it makes sense to enable or disable it. We actually proposed 2 different options in the mail thread. Option 1. Fetch/Do not fetch, all group members (default disabled) Option 2. Resolve Nested Groups, here I think the default should depend on what the server offers. If it is IPA with its memberof we can always properly resolve nested groups with almost no effort, so we should have nested groups enable by default as we encourage using them in the server. For other servers I am not sure what is the best default. In general having it on by default is not a bad idea, unless the server has been managed so badly that nesting causes issues. The main reason for turning it off by default for rfc2307bis is IMO that it causes lots of unneeded LDAP lookups even when no nested groups are used. In initgroups() you'll have to read every groupmember to check if it probably is another group. Another way would be to make this a property of the schema you choose, and differentiate between rfc2307bis and rfc2307bis+nested groups by having a different name. 4) Add marking to the objects. Complete mark is put on the user object when all groups he is a member of are fetched. The groups that were fetched and were not in the cache are marked as incomplete. This is only on initgroups calls, and I think the first part (properly marking the user) is already implemented, we only need to mark the groups differently. When the group members are enumerated for a group all users for a group should be fetched and group should be marked as complete, users fetched by this lookup that were not in the cache are marked as incomplete. Why? Or do you mean incomplete wrt to the initgroups() call for that user. I think we could manage by simply marking users as expired, although this may cause issues if we go offline, as we do not have uid/gid and other fields ... probably we can simply leave those fields off, and this will automatically make them incomplete. We would have to make sure the rest of the code can cope (and filter out) these users when we are offline. Are you talking about the rfc2307 case, were dummy user object could be created? In the other cases (IPA, rfc2307bis) the complete user objects (including gid, uid,...) should be read from LDAP IMO. Reading only a subset there has no real advantage IMO. In the implementation there is probably no difference between the case when entry does not exist or or has incomplete status. Indeed, incomplete entries need to be revalidated (if online) or just filtered (when offline). In both cases same action needs to be taken. In both cases we need to fetch an entry. So I guess we really need just the complete mark. The difference is between the online and the offline case, but in the end yes, the complete mark is what will validate the entry for use. Ralf ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
Re: [SSSD] [PATCH] Check for controls before using them
On Fri, Sep 10, 2010 at 05:05:21PM +0200, Jakub Hrozek wrote: On 09/10/2010 11:16 AM, Sumit Bose wrote: rebased versions attached. bye, Sumit Ack to both patches, but may I suggest that the attached patch be squashed in? Perhaps it would make for a little more readable code. yes, please do, ACK to both changes. bye, Sumit ___ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
