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:
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.
> 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?
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.
> 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?
There is no global definition of 'normal' for non-system users.
> 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?
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.
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!
xguest is not default in F11-Preview-x86_64-Live.iso. see Bug 496488 "Comment #1 From Matthias Clasen (mclasen) 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."