[SSSD] Behaviour of getgrnam/getgrgid

Simo Sorce ssorce at redhat.com
Fri Sep 10 13:34:22 UTC 2010


On Fri, 10 Sep 2010 09:06:29 -0400
Dmitri Pal <dpal at 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



More information about the sssd-devel mailing list