GNU bug report logs - #53631
coreutils id(1) incorrect behavior

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#53631: closed (coreutils id(1) incorrect behavior)
Date: Fri, 04 Feb 2022 23:00:03 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 4 Feb 2022 14:59:20 -0800
with message-id <0637488f-498d-be16-95c3-11c722760411 <at> cs.ucla.edu>
and subject line Re: bug#53631: coreutils id(1) incorrect behavior
has caused the debbugs.gnu.org bug report #53631,
regarding coreutils id(1) incorrect behavior
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
53631: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=53631
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
To: bug-coreutils <at> gnu.org
Cc: "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
Subject: coreutils id(1) incorrect behavior
Date: Sun, 30 Jan 2022 03:52:29 +0300

Hi, bug-coreutils@!

Recently I found an issue in the coreutils id(1) behavior. For coreutils
v8.32-165-g18dbcae25, `id username` prints user and group IDs for the
first matched user with the identical UID. In the case where there are
several users with the identical UID in the system it can be misleading.

Example:

	# useradd user1
	# groupadd somegroup
	# useradd -o -u "$(id -u user1)" -g "$(id -G user1) -G somegroup user2
	# id user1
	uid=1027(user1) gid=1027(user1) groups=1027(user1)
	# id user2
	uid=1027(user1) gid=1027(user1) groups=1027(user1)
	# su - user2
	$ id
	uid=1027(user1) gid=1027(user1) groups=1027(user1),1028(somegroup)

Expected behavior is:

	# id user1
	uid=1027(user1) gid=1027(user1) groups=1027(user1)
	# id user2
	uid=1027(user1) gid=1027(user1) groups=1027(user1),1028(somegroup)

Looking at the code, I found that id uses parse_user_spec() to obtain
euid of username (or uid) command line argument, and then it obtains all
the rest needed information by this euid.

	for (; optind < n_ids; optind++)
	{
	  struct passwd *pwd = NULL;
	  char const *spec = argv[optind];
	  /* Disallow an empty spec here as parse_user_spec() doesn't
	     give an error for that as it seems it's a valid way to
	     specify a noop or "reset special bits" depending on the system.  */
	  if (*spec)
	    {
	      if (parse_user_spec (spec, &euid, NULL, NULL, NULL) == NULL)
		{
		  /* parse_user_spec will only extract a numeric spec,
		     so we lookup that here to verify and also retrieve
		     the PW_NAME used subsequently in group lookup.  */
		  pwd = getpwuid (euid);
		}
	    }


-- 
   WBR,
   Vladimir D. Seleznev

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
Cc: 53631-done <at> debbugs.gnu.org
Subject: Re: bug#53631: coreutils id(1) incorrect behavior
Date: Fri, 4 Feb 2022 14:59:20 -0800

[Message part 4 (text/plain, inline)]

Thanks for the bug report. I installed the attached patch, which I hope 
fixes things for you, and am boldly closing the bug report.

This fix depends on the latest lib/userspec.c from Gnulib; see 
<https://lists.gnu.org/r/bug-gnulib/2022-02/msg00000.html>.

[0001-id-print-groups-of-listed-name.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.