[SSSD] [PATCH] Save dummy groups to cache during initgroups (sssd-1.2)

Simo Sorce ssorce at redhat.com
Wed Oct 6 12:47:29 UTC 2010


On Wed, 06 Oct 2010 14:43:03 +0200
Jakub Hrozek <jhrozek at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/06/2010 01:56 PM, Simo Sorce wrote:
> > For getgroupslist you cannot use fake groups. You *must* fetch the
> > real groups to get the real GID.
> > Returnig gid = 0 would be an enormous security issue, and in general
> > returning any arbitrary GID would be an error.
> > 
> > In general I think fake groups have very limited to no use, we could
> > probably do without them, given that as soon as a user login you
> > *must* fetch all his groups anyway because you need the correct GIDs
> > in order to set up credentials.
> > 
> > Actually I am failing to see a case where using a fake group will
> > not result in fetching the group a second later anyway ... do you
> > have an example ?
> > 
> 
> I am not saving 0 or arbitrary, I am saving the real GID of the group
> - remember that we search for groups the user is a member of during
> initgroups.
> 
> That way, I can just save the object that contains the group name, the
> GID and the single member. That means we save ourselves from saving
> all the other users the group might have. Consider the example one of
> our users described - on a university, each student is a member of a
> "students" group that, in his case, contains 20k entries.
> 
> At the same time, because the group is expired, running getgrnam or
> getgrid will result in refreshing the group entry and returning all
> the users.
> 
> Anyway, I have found a bug that I introduced as a result of review of
> the same patch in master, so new patches are attached again.

Ok, the name really threw me off, if the group is real, then why call
it fake ?
In this case the group is simply incomplete (no memberships) but it is
not fake at all. Can you please s/fake/incomplete/ (or
s/fake/no_members/) so that it is clear what is going on here ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the sssd-devel mailing list