bug#53631: coreutils id(1) incorrect behavior

[Vladimir D. Seleznev]

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