Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: trinkle@cs.purdue.edu
Newsgroups: comp.sys.sun
Subject: Bug in SunOS 4.0.3 /usr/ucb/groups command
Keywords: SunOS
Message-ID: <5160@brazos.Rice.edu>
Date: 20 Feb 90 16:05:51 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 66
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 53, message 1

The groups command does not correctly display all groups for the current
user.  Note the difference in output between the two commands shown in the
script below.  The getgroups program is a trivial C program that calls
getgroups(2) and prints out the results.  The groups command incorrectly
omits the group "wheel".

======================================================================
Script started on Tue Feb 20 11:03:05 1990
orion 1: cat getgroups.c
#include <sys/param.h>

main()
{
    int i, ngroups, groups[NGROUPS];

    if ((ngroups = getgroups(NGROUPS, groups)) >= 0)
        for (i = 0; i < ngroups; i++)
            printf("group: %d\n", groups[i]);
    else
        perror("getgroups");
}
orion 2: cc -o getgroups getgroups.c
orion 3: ./getgroups
group: 143
group: 10
group: 53
group: 1005
group: 0
group: 83
group: 3
group: 2
orion 4: groups
trinkle adm kernel nic sunsrc source staff
orion 5: cat /etc/group
wheel:*:0:
bala:*:557:
cew:*:558:
+:
orion 6: ypmatch wheel group.byname
wheel:*:0:root,bingle,hare,clw,krf,jtk,sah,abc,rlw,trinkle,wilson,hammer,dgc
orion 7: whoami
trinkle
orion 8: 
script done on Tue Feb 20 11:04:05 1990
======================================================================

The surface problem is that the groups(1) command in /usr/ucb does an
unnecessary check against the members of a group before printing out the
group name.  This is ridiculous because you are in the group (if
getgroups(2) says you are) regardless of the current contents of the group
file (or YP database).

The root cause of this problem is inconsistent behavior of initgroups(3)
and getgrgid(3) concerning a mixture of local (/etc/group) and YP group
information.  According to the group(5) man page, a local entry can
override the password field for an entry, but not the gid field.  There is
no explicit mention of the member field when an entry appears both locally
and in the YP map.  A getgrgid(3) call for a group entry that appears
locally only returns the local information, not the combination of the
two, but initgroups(3) behaves as if the effective member field is the
union of the two entries.  This anomaly should be documented.

Daniel Trinkle			trinkle@cs.purdue.edu
Dept. of Computer Sciences	{backbone}!purdue!trinkle
Purdue University		317-494-7844
West Lafayette, IN 47907