Bug 174205 - Change process for selecting GID's
Change process for selecting GID's
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: system-config-users (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-25 16:10 EST by Robin
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-06 15:06:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robin 2005-11-25 16:10:13 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):


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.
Comment 1 Dave Brown 2005-11-29 23:04:12 EST
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.
Comment 2 Robin 2005-11-30 10:35:24 EST
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?
Comment 3 Brian O Smith 2005-12-01 12:17:11 EST
Wouldn't it also be better to allow addition of a user to an existing group
through the add user popup?
Comment 4 Dave Brown 2006-01-26 22:50:02 EST
Looks like bug #151974 contains is an RFE to fix this with a possible solution 
already posted by someone at RH
Comment 5 Robin 2006-02-09 13:17:24 EST
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.
Comment 6 Christian Iseli 2007-01-22 05:26:56 EST
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.
Comment 7 Robin 2007-01-22 12:41:46 EST
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.

Comment 8 Robin 2007-02-06 15:06:25 EST
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.

Note You need to log in before you can comment on or make changes to this bug.