[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