Multiple group membership?

[Cathey, Jim]

We're having a problem with multiple group membership.
(I thought it was working at one point, but at the
moment it appears not to be.)

Our appliance's privilege strategy involves all
higher-privilege users automatically being a member
of all lower-privilege groups.  To wit (simplified):

> cat /etc/passwd
root:x:0:0:root:/:/bin/sh
one:x:500:503::/tmp/users/one:/bin/sh
two:x:503:502::/tmp/users/two:/bin/sh
three:x:502:501::/tmp/users/three:/bin/sh
four:x:501:500::/tmp/users/four:/bin/sh
> cat /etc/group
root:x:0:root,one,two,three
a:x:503:one,two,three
b:x:502:one,two,three
c:x:501:one,two,three
d:x:500:one,two,three,four
>

If you are "root", say, and switch to "one",
given the above database you should automatically
be a member of the root,a,b,c,d groups.  But we're not:

> id -a
uid=0(root) gid=0(root)
> su -s /bin/sh - gss
> id -a
uid=500(one) gid=503(a)
>

This is Busybox 1.14.2, and id 7.4 from coreutils.
I _expect_ output like:

uid=500(one) gid=503(a) groups=root(0),a(503),b(502),c(501),d(500)

Even if you login (Busybox) it's the same.  I was looking
at initgroups() in pwd_grp.c, and it looked fairly plausible,
except that it looked to me like getgrouplist_internal()
was _excluding_ group lines that matched your target (primary?)
group (OK) or one that had your name in it (not OK?).

Am I way off base here?  This _is_ supposed to work, innit?
The appliance generally has g=u permissions, which relies
upon the group lists being there.  It's having trouble, a
high-privileged (a) user is unable to manipulate
0664 root/root files, etc.

I could have sworn this worked when we released the first
appliance, several years ago, but recently selected admin
tasks are failing on new pending releases.

-- Jim