Description of problem: RH's usage of unique GID and UID is nice from a security point of view. It can cause problems if extra groups are added amongst the added users. At present, if you add a group and then go and add another user, the GID's are no longer tied to the individial UID's. Version-Release number of selected component (if applicable): How reproducible: All the time. Steps to Reproduce: 1. Create some users - default 2. Add a group. 3. Add more users. Actual results: The first set of users have matching GID's and UID's. Adding the group changes the available GID's so the rest of the added users now do not have matching GID's and UID's. This can cause problems down the road or with some poorly written applications. Expected results: Under the present system, this is expected. Additional info: A suggestion is to change the way GID's are picked for groupadd and config-system-users selects the next GID. For the addition of a user, don't change anything. For the addtion of a group, have the GID's selected in reverse from the GID_MAX value from /etc/login.defs towards GID_MIN. If I add a group with the GID_MAX set for 60,000, then it will be numbered 60,000. The next group I add will be 59,999. The next group would be 59,998. Add a user and it will be in the 500's as expected. See Bugs 151974, 171124 and 174204.
I believe there is a better (however a bit more difficult solution) to this RFE. By making the GIDs descend from 60000 while the UIDs still ascend from 500 there exists the possibility of these 2 numbers colliding if a server has more than 59500 users / groups. I believe the better solution is to ensure that the useradd programs (useradd / luseradd / system-config-users) select a unique uid / gid combo when adding a new combo (ie a number that is not currently utilised by either a group OR a user). This way you can have as many users as you want and not have to worry about uid/gids not matching nor uids/gids colliding when you hit the 59500 barrier. Hopefully these programs all use a common "selectUID" function so there would only need to be 1 code change but based on some input from a discussion on the Fedora list this doesnt seem to be the case. Thought i'd add my 2 cents.
I used 60,000 as a arbitrary number as something to work with for this RFE. If Fedora (as stated on the fedora list) can handle 2^32 GID's then why not start the GID's at 2^32-1 and continue from there? Basically what I think would work is the Groups start at the highest GID possible and the users at the lowest GID. Even though the search for UID/GID pairs and the next available GID should be easy, I think it would be even easier to work down from the top of the GID's. This also means all the users will be sequential without holes in the UID's. I for one prefer to group all my users in one area groups in another. It makes it easier to visually go through. Does this clear up the mud?
Wouldn't it also be better to allow addition of a user to an existing group through the add user popup?
Looks like bug #151974 contains is an RFE to fix this with a possible solution already posted by someone at RH
That looks like it would fix one problem but doesn't address the idea of grouping all locally added groups isolated from the users for ease of administration.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
I have just installed FC6 so I don't know if this issue exists in FC6. I will have to test to see if this RFE should stand or be closed. I will do my best to get a response back this week.
I have been busy and just tested. Under the FC6 method, the user is created with their private group and same UID/GID numbers, even if there are groups between. It does leave empty user locations but it is better than the old method. As FC3 and FC4 are at EOL, close this report.