Re: ID Numbering in Group and Passwd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dave Brown wrote:
I can see 2 ways to resolve the issue from a Fedora development perspective.

1. Similar to the suggestion you have put forward below - Change UID_MAX to say 40,000 and change GID_MIN to 40,001. That will stop uids and gids from colliding and is a pretty easy solution to implement from a change perspective. Raises a problem tho that what UID will the 39,501th user have? We cant just increase the UID_MAX as there'll be groups using the numbers above 40,000 and we'll run into the same problem as we're having now. Chances are you'll be using NIS or LDAP if you've got this many users but its probably not good practice to be assuming the user management practices of the masses.

2. Change the useradd / luseradd code to find the lowest unique uid / gid combination when creating any new user. This is harder to implement because it involves rewriting the underlying code of useradd but it is a more complete and scalable solution because you can change the UID, GID MIN, MAX values to whatever and it'll still work and users will always have their uid equal to their gid. I tend to favaour this solution because of it's completeness and scalability.

Robin / Others - what do you think? Depending on the general consensus I'll probably submit a feature enhancement request.

In response to Tim and Justin - you'd hope that the CLI and GUI tools doing the same thing would be using the same underlying code / library to achieve it so there is consistency across the 2 tools but it looks like theyre not :o(

Thanks all for your responses.

Dave,

Interesting.

I played with the GID_MIN last night and I found something interesting.

If I use groupadd, it works. If I use the system-config-users tool and click on add group, it doesn't work. The group added is the next available GID. If the GID_MIN is set for 5000, I still ended up with a GID of 524. Thus the GUI tool isn't working as expected. This is a bug as I see it.

Now to solve the problem of collision, how about having the groups work from max to min? If GID_MAX is 60,000 and GID_MIN is 40,000, then the first group used is 60,000. The next would be 59,999, etc. This would expand the range between possible collision points even further. If the underlying code is going to be changed, this may be a better way to go.

Using the reverse method for groups would even remove the necessity to set GID_MIN unless there are 40,000 unique groups which I find really impossible.

Hope this helps.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux