Dave Brown wrote: > I've noticed a bit of an interesting thing with regards to the numbering > of new users and groups when using the useradd and groupadd (and > luseradd / lgroupadd) commands. > > Fresh system with no user accounts on it. > Create a group called "myfamily" using "groupadd myfamily" - the file > /etc/group now has the entry "myfamily:x:500". > Create the user "brother" using "useradd brother" - the file > /etc/passwd now has "brother:x:500:501::/home/brother:/bin/bash" and > /etc/group has "brother:x:501" > > As you can see the utilities have created the user brother with a userid > of 500 and a groupid of 501. All the system accounts (and if you created > any users before you created the group) will have the groupid equal to > the userid. The unequal userid / groupid combo doesnt cause a problem as > the home directory permissions created for the user are fine. > > I've done a fair bit of work with user accounts / groups stored in > OpenLDAP and have had to deal with referencing user accounts and > changing permissions etc by the userid/groupid and not by the name and > have found recently that the above behaviour has been causing me > problems as I have been (stupidly?) assuming that the users groupid is > the same as their userid and inadvertently granting group rights to the > wrong user / group. Talk about creating myself a security problem!!! > > Im interested to hear what other people think about this. I am just > being pedantic :o) Does anyone think that the behaviour of these tools > should be changed to utilise a user/group id that is unique within BOTH > the passwd and group files? Has anyone encountered other issues as a > result of this? If im encountering this problem should I just accept it > and change my login.defs file so all userids start at 500 and all groups > at 1000. > > By the way i'm using FC4 with the all the latest patches, I cant > remember if this behaviour happened on earlier FCs or RHELs and I dont > have any machines with these OSs handy to give it a quick test. > > Cheers > Dave Brown > The issue is you have already used the group id that should have been given to user 500. I create custom groups outside the range of the number of users I expect on the system. At home I created custom groups that were in the 1000's. At work we use NIS and when I setup my computer to Linux, I had the wrong user and group id's for the NIS server as I setup the box before I had NIS working. What a mess that caused for me. You are correct that it is a security issue as many items are controlled by id/group numbers. Recently moving from FC1 to FC4 showed this again as I re-created all the account info. Of course I had the same problem you did as the groups and users were created out of order in the original install in their home directories. It took some time of moving groups around and doing chown chgrp on various directories to get permissions correct again. At least now I have room to add some more users without getting into the custom groups. Maybe the adduser tool should automatically create custom groups in a high range, such as 60,000 by default. If you just want to add a group and not user.

Craig White wrote: > On Wed, 2005-11-23 at 10:46 -0700, Robin Laing wrote: > >>Dave Brown wrote: <snip> > > ---- > I think that you will a number of these 'defaults' can be adjusted by > editing: > > /etc/default/useradd > /etc/login.defs > > Craig > > Hey, I learned something today. In /etc/login.defs, # # Min/max values for automatic uid selection in useradd # UID_MIN 500 UID_MAX 60000 # # Min/max values for automatic gid selection in groupadd # GID_MIN 500 GID_MAX 60000 may solve the whole mess. It may be a nice idea to change these defaults to prevent this headache in the future. I will play with this at home and then submit an enhancement request if it works as I would like. Thank you for the info. Robin -- fedora-list mailing list fedora-list(a)redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

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.

Robin Laing wrote: >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. With the Red Hat standard "user private groups" (one group per user), all you need is 40000 users. In a big university or company, that's not impossible. http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/s1-user... James.

On Thu, 2005-24-11 at 09:31 +0000, Dave Brown wrote: >Robin / Others - what do you think? Depending on the general consensus >I'll probably submit a feature enhancement request. If you do enter a RFE, can you send a reply to this thread with bugzilla #? I'd like to watch it since I've recently run into this problem - it's a major pain in the ass. Regards, Ranbir

I have had a look at the RFE you filed and to be honest i disagree with the way you have asked for it to be fixed. By selecting the GIDs in decending order from 60,000 down and the uid ascending from 500 there still exists the possibility for these 2 numbers to collide if you have more than 59500 users / groups. Granted this is a large number but for big institutions / companies this isnt unreasonable. I personally have worked with two installations that this numbering scheme would have caused problems. I believe that the underlying code should be changed so that when adding a user the lowest available number which is not currently used by either a group or user should be the one selected. That way you can have as many users as you want (up to 2^32 of course :o) without running into any clashes. I will add a note to your RFE explaining my thoughts and see what RedHat reckon. Thanks for your input. Cheers Dave On 26/11/05, *Robin Laing * <Robin.Laing(a)drdc-rddc.gc.ca <mailto:Robin.Laing@drdc-rddc.gc.ca>> wrote: Kanwar Ranbir Sandhu wrote: > On Thu, 2005-24-11 at 09:31 +0000, Dave Brown wrote: > >>Robin / Others - what do you think? Depending on the general consensus >>I'll probably submit a feature enhancement request. > > > If you do enter a RFE, can you send a reply to this thread with bugzilla > #? I'd like to watch it since I've recently run into this problem - > it's a major pain in the ass. > > Regards, > > Ranbir > I entered an RFE this afternoon. Bug 174205 Robin.

Aaaah, now i see what you're getting at :o) You explained it pretty well, I just didnt cotton on to the fact that you were using 60,000 as an arbitrary number. I spose we'll have to wait and see how the RFE goes - hopefully there is some sort of solution implemented whether its the high / low stuff or the uniqueness or something else Redhat come up with.

On Wed, 2005-11-23 at 17:25 +0000, Dave Brown wrote: > I've noticed a bit of an interesting thing with regards to the > numbering of new users and groups when using the useradd and groupadd > (and luseradd / lgroupadd) commands. > > Fresh system with no user accounts on it. Create a group called > "myfamily" using "groupadd myfamily" - the file /etc/group now has the > entry "myfamily:x:500". Create the user "brother" using "useradd > brother" - the file /etc/passwd now has > "brother:x:500:501::/home/brother:/bin/bash" and /etc/group has > "brother:x:501" > > As you can see the utilities have created the user brother with a > userid of 500 and a groupid of 501. All the system accounts (and if > you created any users before you created the group) will have the > groupid equal to the userid. The unequal userid / groupid combo doesnt > cause a problem as the home directory permissions created for the user > are fine. When I've just used the GUI tool, each new user has has the same UID and GUI, each incrementing by one for each new user. But if I added a user with a manual UID, using the GUI, the GID would automatically be one higher than the last automatically generated GID. Using the CLI, they'd both get the same GID and UID. e.g. On a system with Name UID GID John 500 500 Martha 501 501 George 502 502 Fred 508 508 If I now added a new user via the GUI, leaving it to pick GID and UIDs, they'd both be 503. But if I added a new users using the GUI, opting to set the UID as 515, it'd set the GID as 503 (the lowest free value). But if I'd added them using the CLI (as 515, again), they'd both be 515. I wish the GUI tool would either let me, also, set the GID, or set them both the same as each other. It might well be that I want to add a few usernames, but put them all into a guests group, for instance. I'd have to do that via the command line (or a script).