This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Volker.Lendecke@SerNet.DE: glibc 2.2.5 and 2.3.2 getgrouplist broken?]


Hi!

I was asked to forward this bug report here.

Please excuse my strong wording at the end, it took me really a while to
see that this *might* not be a Samba problem...

Volker

----- Forwarded message from Volker Lendecke <Volker.Lendecke@SerNet.DE> -----

Date: Fri, 27 Jun 2003 17:47:17 +0200
From: Volker Lendecke <Volker.Lendecke@SerNet.DE>
To: samba-technical@samba.org
Subject: glibc 2.2.5 and 2.3.2 getgrouplist broken?
Sender: Volker Lendecke <vlendec@sernet.de>

Hi!

I've just tried to chase down a segfault in Samba. The Realloc in
auth_util.c:670 segfaulted for a customer of mine on a glibc system. The
problem is that he had a user with 39 groups in /etc/group imported via
winbind. Ok, this is too much, but at least we should not segfault.

But it's not samba's fault: It's the libc's getgrouplist function. The
following is the code from the debian libc6 2.2.5 source package for
getgrouplist:

/* Store at most *NGROUPS members of the group set for USER into
   *GROUPS.  Also include GROUP.  The actual number of groups found is
   returned in *NGROUPS.  Return -1 if the if *NGROUPS is too small.  */
int
getgrouplist (const char *user, gid_t group, gid_t *groups, int *ngroups)
{
  gid_t *newgroups;
  long int size = *ngroups;
  int result;

  newgroups = (gid_t *) malloc (size * sizeof (gid_t));
  if (__builtin_expect (newgroups == NULL, 0))
    /* No more memory.  */
    return -1;

  result = internal_getgrouplist (user, group, &size, &newgroups, -1);
  if (result > *ngroups)
    {
      *ngroups = result;
      result = -1;
    }
  else
    *ngroups = result;
      
  memcpy (groups, newgroups, *ngroups * sizeof (gid_t));

  free (newgroups);
  return result;
}

The memcpy simply assumes to have room in the "groups" array for
anything that it finds in /etc/group. We allocate NGROUPS_MAX for the
array and hand that to libc which then happily overwrites past the end
of the array.

To me this does not really look usable. BTW, the code in glibc-2.3.2
looks exactly the same.

So what do you think about never using that crap?

Volker




----- End forwarded message -----

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]