Bug 151974 - RFE - useradd switch to demand UID and GID be the same
Summary: RFE - useradd switch to demand UID and GID be the same
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils   
(Show other bugs)
Version: 4
Hardware: All Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: David Lawrence
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-23 22:59 UTC by Michael A. Peters
Modified: 2008-02-15 22:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-15 22:58:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
update candidate (1.01 MB, application/octet-stream)
2005-03-24 13:10 UTC, Peter Vrabec
no flags Details

Description Michael A. Peters 2005-03-23 22:59:39 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050322 Firefox/1.0.1 Fedora/1.0.1-6

Description of problem:
I would like a useradd switch so that when useradd is allowed to decide the UID and GID, it will pick an available pair that is the same. This would be nice with the -r switch to create a system user.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Fresh system with default UID/GID's already assigned
2. useradd -r foobar

Actual Results:  With the above scenario, UID/GID 99 belongs to user/group nobody - but there is also a GID 100 for a group called users. There is no user with UID 100.

So useradd with the -r switch will use a UID of 100 for the user it is adding, since 99 is the highest existing UID below what common users have, and it it will use a GID of 101 because 100 is the highest GID below groups for common users.

That's fine for default behaviour, but a switch to ask it to find the lowest pair of same UID/GID that meets the criteria (with -r switch that would be above existing system user accounts but below common user accounts) would be a sweet addition.

Additional info:

Comment 1 Michael A. Peters 2005-03-23 23:06:49 UTC
If that wasn't understandable - a switch to make it pretend a free UID is taken
if the GID actually is (and vice versa) so that when it does its thing, the UID
and GID it chooses will be the same.

Comment 2 Peter Vrabec 2005-03-24 13:10:30 UTC
Created attachment 112290 [details]
update candidate

Could u test it please and let me know if it works.

Comment 4 Robin 2006-02-09 18:16:51 UTC
See bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174205 for another
take on this issue.  This patch would fix one problem but still could leave
blanks spots in the UID.  As more and more users or groups get added, this could
make a mess.  In bug, 174205, I recommeded that GID only assignments work
backward from GID_MAX towards the UID list.

Comment 5 Christian Iseli 2007-01-20 00:12:22 UTC
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 ?


Comment 6 Matthew Miller 2007-04-06 15:08:10 UTC
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest
this issue on a current release or on the latest development / test version, we
would appreciate that. Otherwise, this bug will be marked as CANTFIX one month
from now. Thanks for your help and for your patience.

Comment 7 petrosyan 2008-02-15 22:58:39 UTC
Fedora Core 4 is not maintained anymore.

Setting status to "INSUFFICIENT_DATA". If you can reproduce this bug in the
current Fedora release, please reopen this bug and assign it to the
corresponding Fedora version.

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