Hi,
The coreutils changelog notes that a bug in id and groups which
overreported the available groups was supposedly fixed in:
2012-04-27 Jim Meyering <meyering@redhat.com>
id,groups: with no user name, print only real and/or effective IDs,
... i.e., don't use the getpw* functions.
Before this change, running groups or id with no user name argument
would include a group name or ID from /etc/passwd. Thus, under unusual
circumstances (default group is changed, but has not taken effect for a
given session), those programs could print a name or ID that is neither
real nor effective.
However this appears to not be the case for id in jessie. If it is
called after only calling setuid(), and not assigning any supplementary
groups or calling setgid(), then it reports something like:
uid=1000(ron) gid=0(root) groups=1000(ron),0(root)
/usr/bin/groups however now does the right thing in jessie (it had this
bug in wheezy).
The id(1) man page is a bit ambiguous about what it should report there,
but SuSv4 is quite clear that:
"If no user operand is provided, the id utility shall write the user
and group IDs and the corresponding user and group names of the
invoking process to standard output."
And since the process above was not actually in group 1000, that should
not have been included.
Given the changelog entry above, it's not clear to me yet if this is
a regression upstream, a regression due to a debian patch, or if the
original fix wasn't actually sufficient. But this is what I know at
this stage.
Cheers,
Ron