On Sun Feb 17 15:42:59 2013, jbenjore wrote: > On Sat Feb 16 16:51:18 2013, demerphq wrote: > > Josh are you able to look into this? As far as I know the last patch > > was from you and was quite significant. > > > > Cheers, > > Yves > > Yves, > The root of the original Darwin problem was that Darwin has NGROUPS_MAX > at 15 which means that the kernel allocates only enough storage for > membership in that many groups. By default I recall, something like 12 > of them are used by default. > > Any LDAP groups or similar must fit within the additional 3 groups for > membership. I vaguely recall that that the $) uses an API which directly > interrogates the kernel and the allocated group membership which means > Perl conforms to the built-in limit of only 15 groups maximum. The > comments in t/op/groups.t say it's the kernel function getgroups(2). > > The `id` and/or `groups` commands however are not limited by the local > machine and report all group memberships, even those that aren't > representable on the local machine. The intent of > 651d4685ebdde5512841551572b29e74605bfc38 if I recall correctly, is to > attempt to test the numeric ids returns from `id` against the numeric > ids returned by $( except when we find more ids than possible. > > It is possible that on Darwin perl's $( should call the libc function > getgrouplist(3) *instead* of getgroups(2). The libc function consults > Open Directory and is not limited by the kernel's NGROUPS_MAX > allocation. > > Further, it is just a rank stupid bug that this code can run and omit at > least a "not ok 1". Apologies for > http://perl5.git.perl.org/perl.git/blob/651d4685ebdde5512841551572b29e74 > 605bfc38:/t/op/groups.t#l120 which clearly allows for a missing "not ok > 1". Josh, Yves: Do we have any more insight into this problem? Thank you very much. Jim Keenan --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=116775Thread Previous