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
