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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53631 in the body.
You can then email your comments to 53631 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 #8 received at 53631 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
Cc: 53631 <at> debbugs.gnu.org
Subject: Re: bug#53631: coreutils id(1) incorrect behavior
Date: Sat, 29 Jan 2022 18:46:00 -0700

Vladimir D. Seleznev wrote:
> 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)

I just tried a test on both FreeBSD and NetBSD and both FreeBSD and
NetBSD behave as you expect.  That would give weight for GNU Coreutils
matching that behavior.

> Example:
> 	# useradd user1
> 	# groupadd somegroup
> 	# useradd -o -u "$(id -u user1)" -g "$(id -G user1) -G somegroup user2

I'll just note that there is a missing ending quote character.  It's
also missing the -m option to create a home directory.  For those who
wish to recreate the test case.

    root <at> turmoil:~# tail -n2 /etc/passwd /etc/group /etc/shadow /etc/gshadow
    ==> /etc/passwd <==
    user1:x:1001:1001::/home/user1:/bin/sh
    user2:x:1001:1001::/home/user2:/bin/sh

    ==> /etc/group <==
    user1:x:1001:
    somegroup:x:1002:user2

    ==> /etc/shadow <==
    user1:!:19022:0:99999:7:::
    user2:!:19022:0:99999:7:::

    ==> /etc/gshadow <==
    user1:!::
    somegroup:!::user2

With the above things are not really a valid configuration.  Therefore
I don't think it is surprising that the utilities don't "figure it
out" completely correctly.  I have never seen user2 used with a
different set of groups than the primary uid specifies.  I think in
practice that will be problematic.  Since the system will use the uid
for such things and the uid would map to a different set of auxilary
groups.  I think in practice this case is a problematic case at the
least.

Note that it is perfectly valid and long standing practice to allow
multiple passwd entries with the same uid number.  That's a technique
to allow multiple different passwords and login shells for the same
account.

[[ I'll further note that use of nscd completely breaks this useful
ability by hashing all duplicate uid entries together.  Like in The
Highlander, with nscd there can be only one.  It's why I never use
nscd anywhere as this makes it not suitable for purpose.  But that's
rather off this topic.  I'll bracket it as an aside. ]]

Bob

Message #11 received at 53631 <at> debbugs.gnu.org (full text, mbox):

From: "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
To: Bob Proulx <bob <at> proulx.com>
Cc: 53631 <at> debbugs.gnu.org, "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
Subject: Re: bug#53631: coreutils id(1) incorrect behavior
Date: Sun, 30 Jan 2022 05:40:17 +0300

On Sat, Jan 29, 2022 at 06:46:00PM -0700, Bob Proulx wrote:
> Vladimir D. Seleznev wrote:
> > 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)
> 
> I just tried a test on both FreeBSD and NetBSD and both FreeBSD and
> NetBSD behave as you expect.  That would give weight for GNU Coreutils
> matching that behavior.
> 
> > Example:
> > 	# useradd user1
> > 	# groupadd somegroup
> > 	# useradd -o -u "$(id -u user1)" -g "$(id -G user1) -G somegroup user2
> 
> I'll just note that there is a missing ending quote character.  It's

Oops! Wrong copying, sorry.

> also missing the -m option to create a home directory.

Yes, but in my system it is handled by CREATE_HOME of /etc/login.defs.
But perhaps I should've provided more general example.

-- 
   WBR,
   Vladimir D. Seleznev

Message #14 received at 53631 <at> debbugs.gnu.org (full text, mbox):

From: Martin Schulte <gnu <at> schrader-schulte.de>
To: Bob Proulx <bob <at> proulx.com>
Cc: 53631 <at> debbugs.gnu.org, "Vladimir D. Seleznev" <vseleznv <at> altlinux.org>
Subject: Re: bug#53631: coreutils id(1) incorrect behavior
Date: Sun, 30 Jan 2022 11:15:23 +0100

Hello Bob!

> > 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)
> 
> I just tried a test on both FreeBSD and NetBSD and both FreeBSD and
> NetBSD behave as you expect.  That would give weight for GNU Coreutils
> matching that behavior.

In addition (and maybe even more important) I expect that "id -u <user>" prints the same result the same result as "id" prints out after <user> as logged in:

root <at> martnix4:~# su - user1
user1 <at> martnix4:~$ id
uid=1002(user1) gid=1002(user1) groups=1002(user1)
user1 <at> martnix4:~$ exit
logout
root <at> martnix4:~# su - user2
user1 <at> martnix4:~$ id
uid=1002(user1) gid=1002(user1) groups=1002(user1),1003(somegroup)
user1 <at> martnix4:~$ exit
logout
root <at> martnix4:~#

So, it really looks like a bug for me...

Best regards,

Martin

Message #19 received at 53631-done <at> debbugs.gnu.org (full text, mbox):

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 1 (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)]

Message #22 received at 53631 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: 53631 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, vseleznv <at> altlinux.org
Subject: Re: bug#53631: coreutils id(1) incorrect behavior
Date: Sat, 12 Feb 2022 21:30:15 +0000

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

On 04/02/2022 22:59, Paul Eggert wrote:
> 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>.

I'll apply the following later to ensure
chown --verbose continues to list numeric ID info.

cheers,
Pádraig

[chown-numeric-id-verbose.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.