Bug 499384 - xguest initial uid (and group id) not sane
xguest initial uid (and group id) not sane
Product: Fedora
Classification: Fedora
Component: xguest (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-06 09:37 EDT by jaminJay
Modified: 2009-05-11 08:32 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-11 08:32:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description jaminJay 2009-05-06 09:37:23 EDT
Description of problem:

When initially installing Fedora 11 Beta on a system with a preserved /home as mounted partition, the initial uid (and group id) of 500 conflict with the likely previous user installations, requiring chowning etc. of all user files when creating users with such pre-existing home directories.  This extends the length of time required to set up such users, and in the circumstances under which this issue was discovered, caused the entire /home partition to be chowned to whichever user was first re-added.  Reporter assumes that there is a sim-link causing this particular relabelling, but believes that, if xguest had a 'sane' uid and group id (i.e. not >=500) this problem would be alleviated.

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

How reproducible:

Install Fedora with xguest onto a system where a previously populated /home partition exists.

Steps to Reproduce:
1. Begin with an existing system where /home is a partition and has multiple users.  Note which user was uid 500.
2. Install Fedora with a custom filesystem layout which propagates said /home partition.  Include the xguest installation.
3. Recreate the user with uid 500.  As 500 is now assigned to xguest, all of the files will need to be reassigned to the new uid.
Actual results:

Files need extensive modification.

Expected results:

Files need minimal modification.

Additional info:
Comment 1 Daniel Walsh 2009-05-06 09:53:16 EDT
xguest is just executing useradd in the post install which is grabbing the next available UID for this user.  The problem is useradd picked out a UID that is in conflict with an existing UID,  

I don't think this should have happened. Not sure why useradd did not realize the UID was in use.  

What are you using for storing of user identity.
Comment 2 jaminJay 2009-05-06 10:24:47 EDT
> What are you using for storing of user identity. 

To what do you refer?  I just leave the home partition as is and recreate the four users (me, my lady and two special users) in the same order they are created every 6 months.

I don't use Kerberos or anything like that, if that's what you mean?
Comment 3 Bill Nottingham 2009-05-06 10:37:10 EDT
As xguest needs to be a normal user id, it's expected to take the next open id in the 'normal' user range. You did an *install*  - in this case, Fedora has no idea what users you may be adding later, so there's no data for it to look at to see what users to avoid.

I don't see how this can be fixed for this case.
Comment 4 jaminJay 2009-05-06 10:45:20 EDT
> I don't see how this can be fixed for this case.

adduser --uid XYZ

where XYZ is a uid not in the 'normal' user range?
Comment 5 Bill Nottingham 2009-05-06 11:15:09 EDT
There is no global definition of 'normal' for non-system users.
Comment 6 jaminJay 2009-05-07 04:05:35 EDT
> As xguest needs to be a normal user id, it's expected to take the next open id in the 'normal' user range.

> There is no global definition of 'normal' for non-system users.

So, which is it?
Comment 7 Bill Nottingham 2009-05-07 09:36:33 EDT
Sorry, a little more verbose.

xguest needs to have a normal user id (i.e., a non-system user). That's normally done by useradd by picking the next non-system id. See /etc/login.defs for the defined range.

You're saying that it should pick one not likely to be used by other local users. However, there's no way to determine what user scheme the local admin might choose - the admin may start at 500, the admin may start at 1000, the admin may start at 20000. There's no range that xguest could logically pick, without additional information from the admin.

If you want to ship a modified login.defs, useradd will change what range it uses; it's not something xguest can use by default, though.
Comment 8 jaminJay 2009-05-10 06:10:36 EDT
Having considered possible solutions, and knowing I'm probably one of few (if any) who will have this problem, and hereafter xguest will mostly be user 500 for new installs, I will accept the likelihood that xguest=uid500 as the new world order.

Thanks for your time and consideration.

Now, on to the next bug discovery!
Comment 9 Flóki Pálsson 2009-05-10 07:51:21 EDT
xguest  is not default in F11-Preview-x86_64-Live.iso.
see Bug 496488 
"Comment #1 From  Matthias Clasen (mclasen@redhat.com)  2009-04-19 14:35:40 EDT   (-) [reply] -------

xguest is a regular user. I just gets created before you have a chance to
create your account, if xguest is included in the initial set of packages.
FWIW, we've taken xguest out of the default install post-beta, so this problem
should not occur with F11 final."

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