bug#52656: (id) utility bug found

[Glenn Golden]

Morteza Ghorbani <morteza.ghorbani@live.com> [2021-12-19 11:01:37 +0000]:
> Hello
> I am Morteza Ghorbani
> While Working with id utility, I found strange behavior.
> Suppose that my username is ‘user1’ , so if I remove user1 from a 
> particular group (e.g. netdev) by the following instruction : 
> gpasswd –delete user1 netdev
> 
> then if I enter the ‘id’ command, I will be noted that nothing has 
> been changed and still see the group which I removed the use1 from. 
> On the other hand, if I enter the command ‘ id user1 ‘, by this way 
> I can see the changes ! 
> 
> In a nutshell, ‘id’ --> does not show the changes while ‘id 
> user1’ shows the changes and its behavior is correct. 
>

The above behavior is expected, and documented in coreutils.info going
back to at least 8.30 (September 2018):

   "Primary and supplementary groups for a process are normally inherited
    from its parent and are usually unchanged since login.  This means that
    if you change the group database after logging in, ‘id’ will not reflect
    your changes within your existing login session.  Running ‘id’ with a
    user argument causes the user and group database to be consulted afresh,
    and so will give a different result."

However, there does seem to be a disconnect between the 'id' man page and
coreutils.info, even in coreutils 9.0, which imo could benefit from some
minor language improvement: The first sentence of the man page says

   "Print user and group information for each specified USER, or (when USER
    omitted) for the current user."

but coreutils.info says

    "‘id’ prints information about the given user, or the process running
    it if no user is specified."

The coreutils.info is probably 'more correct', because it seems to explain
why the no-user-specified behavior is the way it is.  Possibly the man page
could be updated to say the same.

Glenn