[SSSD] Behaviour of getgrnam/getgrgid

Simo Sorce ssorce at redhat.com
Thu Sep 9 15:48:09 UTC 2010


On Thu, 9 Sep 2010 16:46:35 +0200
Ralf Haferkamp <rhafer at 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 <sgallagh at 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



More information about the sssd-devel mailing list