Bug#755714: /usr/bin/id: lies about the available groups

2014-07-27 Thread Pádraig Brady
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  
> 
>   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 debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#755714: /usr/bin/id: lies about the available groups

2014-07-22 Thread Ron
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  

  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


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15-trunk-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-1
ii  libattr1 1:2.4.47-1
ii  libc62.19-4
ii  libselinux1  2.3-1

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org