Red Hat Bugzilla – Bug 174205
Change process for selecting GID's
Last modified: 2007-11-30 17:11:17 EST
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):
All the time.
Steps to Reproduce:
1. Create some users - default
2. Add a group.
3. Add more users.
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
Under the present system, this is expected.
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
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
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 ?
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.