On 07/22/2014 05:18 PM, Ron wrote: > Package: coreutils > Version: 8.21-1.2 > Severity: normal > > 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 <[email protected]> > > 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
I think the above referenced fix was only partial, and the complete fix should now be in coreutils-8.23 which includes: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=408461c0 thanks, Pádraig. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
