Re: ATTENTION: Tcl/Tk transition

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Oct 28 10:48, Corinna Vinschen wrote:
> On Oct 28 03:20, Yaakov (Cygwin/X) wrote:
> > On Fri, 2011-10-28 at 09:56 +0200, Corinna Vinschen wrote:
> > > > On Thu, Oct 27, 2011 at 10:11:03PM -0500, Yaakov (Cygwin/X) wrote:
> > > > >On Thu, 2011-10-27 at 10:07 +0200, Corinna Vinschen wrote:
> > > > >> Cool, thanks!  You don't want to take over ruby maintainership as well,
> > > > >> do you? :}
> > > > >
> > > > >Would your adding getgrouplist(3) be a fair price? :-)
> > > > >
> > > > >http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
> > > > >
> > > > >I need this for an attempt to port polkit-1, and I haven't learned that
> > > > >part of the codebase yet.  Deal? :-)
> > > 
> > > Deal!
> > 
> > Done.  ruby-1.8.7-p352 with separate ruby-tcltk package is ready.
> 
> Cool, thanks!
> 
> > > I assume you want the full group list, represented by the user's token
> > > if one would like to construct the token, right?
> > 
> > See the "spec" noted above, but if ngroups is correctly sized, all
> > groups to which the given user belongs are returned AND the given group
> > even if the user is not a member thereof.
> 
> Uh, maybe I wasn't clear.  I didn't talk about Linux or so, I was
> just refering to two possible implementations on Cygwin, one looking
> into /etc/groups only, the other fetching the information from the OS.
> But that was YA ENOCOFFEE question since I gave up on using the
> supplemetary groups from /etc/group anyway.  Only what the OS allows
> should count.
> 
> > > If so, that requires to create a SID list by fetching the information
> > > from the local SAM and AD, quite similar to the initgroups function.
> > > 
> > > On second thought, that would be practically identical to our
> > > initgroups32 function, except for the cygheap->user.groups.update_supp
> > > call, which would be replaced by filling the group list given as
> > > argument.
> > 
> > That makes sense, given that on BSD[1], initgroups(3) is basically
> > getgrouplist() followed by setgroups().  The primary difference will be
> > adding the given group if not a member and assuring proper size of
> > ngroups.  (Yes, I did look into this myself once upon a time.)
> 
> Yup, I'm comparing the implementations of glibc and FreeBSD right
> now.  The Linux getgrouplist man page doesn't tell anything of
> the handling of NULL pointers, so I had to use the source to see
> how they handle this.  FreeBSD asserts, GLibc just crashes.  FreeBSD
> also allows a NULL group pointer if *ngroups is 0.  I like FreeBSD 
> better here, so I'll do the same.

Done.  Please give it a try.  I used this STC for testing:

$ cat > ggl.c <<EOF
#include <stdio.h>
#include <grp.h>

int
main (int argc, char **argv)
{
  int ret, ngroups;
  gid_t groups[256];

  ngroups = 0;
  ret = getgrouplist (argv[1], 20000, NULL, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  ngroups = 1;
  ret = getgrouplist (argv[1], 20000, NULL, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  ngroups = 1;
  ret = getgrouplist (argv[1], 20000, groups, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  ngroups = 256;
  ret = getgrouplist (argv[1], 20000, groups, &ngroups);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);
  for (ret = 0; ret < ngroups; ++ret)
    printf ("  %d%s", groups[ret], ret < ngroups - 1 ? ", " : "\n");

  ret = getgrouplist (argv[1], 20000, groups, NULL);
  printf ("ret = %d, ngroups = %d\n", ret, ngroups);

  return 0;
}
EOF

The last getgrouplist call should always abort due to an assertion.
The first call should abort if you don't give an argument.  The group
20000 is an arbitrary group in my /etc/group file which exists, but
which no user is a member of.

Please note that getgrouplist does not always add the gid to the
group list in my implementation.  The requirement is that it must
exist in /etc/groups.  There's no good reason to add a group to
the group list if the group isn't backed by a OS SID.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat