On Friday 10 September 2010 15:34:22 Simo Sorce wrote:
On Fri, 10 Sep 2010 09:06:29 -0400
Dmitri Pal <dpal(a)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