From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.8.1.12) Gecko/20080208 Fedora/2.0.0.12-1.fc8 Firefox/2.0.0.12 Description of problem: When lusermod is invoked with "-g" parameter, it modifies only /etc/passwd file but does not modify /etc/group file. After this action lid utility is unable to display the user information. Version-Release number of selected component (if applicable): libuser-0.52.5-1 How reproducible: Always Steps to Reproduce: 1. luseradd testuser 2. lid testuser 3. lusermod -g 1567 testuser 4. lid testuser Actual Results: The step 4) produces no output. Expected Results: The step 4) produces the same output as step 2) except for gid=1567. Additional info:
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Thanks for your report. (lusermod -g) only changes the primary group ID; it can be used to change the group ID of the user to a different existing group. Because a group with the new group ID may already exist, lusermod cannot in general rename the group. (If you want to change a group ID of an existing group, use lgroupmod; lgroupmod will also update all users to use the new group ID.) Therefore, (lid) cannot show "testuser(gid=1567)". Arguably it could show "(gid=1567)" (with an empty group name) - but the situation is caused by an incorrect configuration and I don't think it's worth it to add a special-case code to lid to handle this case. Instead, lusermod in Fedora >= 9 will output a warning if the new group ID does not refer to an existing group.