== The theoretical right way to check if an account is in a Unix group

If you are checking once to see if an account is in a group, there is a
simple and obvious approach (omitting some details):

.pn prewrap on
>  grp = getgrnam(GRPNAME);
>  getgrouplist(pwent->pw_name, pwent->pw_gid, &groups, &ngroups);
>  for (i = 0; i < ngroups; i++) {
>    if (groups[i] == grp->gr_gid)
>      return 1;
>  }

There is just [[one problem ../linux/UbuntuAccountsServiceProblems]]
with this: on many systems, _``getgrouplist()''_ will re-scan and
re-parse _/etc/group_ every time you call it. If you call it only
once or twice this usually doesn't matter. If you call it a lot,
this matters a lot (especially if _/etc/group_ is big).

In theory, the better check is simple. Instead of getting the login's
group list and seeing if the group's GID is in there, you work the other
way around: you get the group's membership (as part of getting the group
entry itself) and then see if the login either has the group's GID as
it's primary group or appears on the list of group members. This avoids
(repeatedly) parsing all of _/etc/group_, especially if you cache the
group entry for the group you care about.

However, these two checks are not equivalent and now you have to decide
what you care about. The first version checks to see if a login has the
*group ID* of a particular group. The second version checks to see if a
login has the *group name* of a particular group. To see the difference,
consider the following group entries:

>  wheel:x:10:jane
>  cog:x:10:fred

Here is the question: is _fred_ in group _wheel_? If we go by GID
the answer is clearly yes; _fred_ will have GID 10 as one of his
supplemental groups when he logs in and be able to access files that are
only accessible to GID 10. But if we go by group name, the answer is no;
_fred_ is in _cog_, not _wheel_, although they have the same GID.  Which
version the software you use cares about is something that you may have
to investigate.

(If you are designing the software, you can decide to make it whichever
is more convenient and useful to you.)

The corollary is that if you really do need the GID version and you want
to be fast for a large number of checks, in theory you need to build
some sort of full in-memory index of _/etc/group_. In practice, however,
duplicate GIDs are extremely rare and usually not intended so you may be
to be able to ignore them. If not, you can at least scan _/etc/group_
once to see if the group you care about has duplicated GIDs.

(The fully general version is to scan _/etc/group_ and accumulate all
of the group entries for groups with the same GID as the group you care
about. Then you check all of their group membership lists. This is going
to require caching in order to make it fast for a large number of logins
and groups.)