[SSSD] Behaviour of getgrnam/getgrgid

Simo Sorce ssorce at redhat.com
Mon Sep 27 19:42:58 UTC 2010


On Mon, 27 Sep 2010 21:37:18 +0200
Ralf Haferkamp <rhafer at suse.de> wrote:

> Am Montag 27 September 2010, 16:37:14 schrieb Simo Sorce:
> > On Fri, 24 Sep 2010 16:31:24 +0200
> > 
> > Ralf Haferkamp <rhafer at suse.de> wrote:
> > > Hi,
> > > 
> > > find updated patches attached. (Rebased against current master)
> > > 
> > > Am Donnerstag 23 September 2010, 20:02:20 schrieb Stephen
> > > Gallagher:
> > > > On 09/20/2010 11:13 AM, Ralf Haferkamp wrote:
> > > [..]
> > > 
> > > > Patch 0001: Ack. This looks fine to me.
> > 
> > Uhmm I think I see an issue in patch 1.
> > 
> > It looks to me that we fail the operation if we have no members in a
> > group as when calling sysdb_attrs_get_el() sdap_save_group() now
> > treats ENOENT just like a fatal error.
> Hm, I am not sure what call to  sysdb_attrs_get_el() you are
> referring to, but if I understand the sysdb_attrs_get_el() code
> correctly it will never return ENOENT.
> It just calls sysdb_attrs_get_el_int with alloc=true in that case the 
> only error that can return is ENOMEN. Did I overlook something?
> IIRC I explicitly tested the code with empty groups.

Uhm I guess I was seeing something that's not there then, sorry :/

> > Although uncommon I think we should handle empty groups.
> Of course.
> 
> > Also I have a cosmetic request. It took sometimes to me to
> > understand what the name sysdb_member_dns meant. Would it be
> > possible to rename it to something like
> > populate_members/resolve/members/fetch_members or something
> > similar ? It would make it easier to understand it is an option
> > that does something like store_members, just different.
> Ok. Find updated patch attached.
> 

ack.

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



More information about the sssd-devel mailing list