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.defsfile 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
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.
On Wed, 2005-11-23 at 10:46 -0700, Robin Laing wrote:
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.
---- I think that you will a number of these 'defaults' can be adjusted by editing:
/etc/default/useradd /etc/login.defs
Craig
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
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
On 23/11/05, Robin Laing Robin.Laing@drdc-rddc.gc.ca wrote:
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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Dave Brown wrote:
- 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.
UIDs and GIDs are supposed to be 32-bit these days (there's a nfsnobody on my system with a UID and GID of 4294967294). So you could start GIDs at 2 billion. That ought to be enough for most people.
On the other hand, not everything out there is 32-bit clean. There'll probably be someone who wants to connect this system to something that only understands 16 bit UIDs.
James.
Dave Brown wrote:
I can see 2 ways to resolve the issue from a Fedora development perspective.
- 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.
- 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.
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-users-g...
James.
James Wilkinson wrote:
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-users-g...
James.
I wasn't talking about user groups. I was talking about groups that don't have specific users. In my case it is shared groups for family files, groups for shared multimedia files that I don't want my kids to view etc.
To explain further.
Users start at 500 as they do now. If I want to add a group such as mpaa-R for R rated DVD's that I stored on my system, they would start at 60,000 if I had GID_MAX set to 60,000.
Lets say I have 12 users and 11 extra groups. This means that the USER GID's are 500-512 The extra groups are 59,989-60,000.
This means that there could be upto 59,489 total users using RH's UID=GID concept before a collision unless more groups were added. No real need to manually select GID's or even to change limits if the defaults are set properly.
All UID/GID combos are still in order if the defaults work as expected.
Does this clear up some of the mud now? :)
Robin.
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
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.
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@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.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Dave Brown wrote:
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@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.
Some times I am not that good at explaining things.
I have added to the RFE taking your comments into account as you will see. I am reposting some of my comments here for the list.
I used 60,00 as an arbitrary number. If Fedora can work with 2^32 GID's then change 60,000 to 2^32 and work from there. It isn't a big deal.
The idea is to search from high to low for GID's and low to high for UID/GID combos.
This also minimizes any holes in the UID/GID mix unless users are deleted.
Thanks for the suggestion.
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 01/12/05, Robin Laing Robin.Laing@drdc-rddc.gc.ca wrote:
Dave Brown wrote:
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@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 thisproblem -
> it's a major pain in the ass. > > Regards, > > Ranbir > I entered an RFE this afternoon. Bug 174205 Robin.Some times I am not that good at explaining things.
I have added to the RFE taking your comments into account as you will see. I am reposting some of my comments here for the list.
I used 60,00 as an arbitrary number. If Fedora can work with 2^32 GID's then change 60,000 to 2^32 and work from there. It isn't a big deal.
The idea is to search from high to low for GID's and low to high for UID/GID combos.
This also minimizes any holes in the UID/GID mix unless users are deleted.
Thanks for the suggestion.
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Dave Brown wrote:
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.
Sometimes I have a problem explaining things without using pictures. I am a visual type of person.
Glad that I wiped some of the mud off of the description. I just think it would be neater and easier to do it this way than having multiple holes in the UID.
As with any suggestion, it can be accepted, modified or denied. But if you don't suggest, it cannot be fixed.
Robin
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).
On Thu, 24 Nov 2005, Tim wrote:
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).
sounds like the GUI tools arent using the UPG scheme where each user is in their own group, not sure if it is a bug, but it seems like it probably is. It just goes to show the command line is the best way to use an OS.
On Wed, 2005-11-23 at 23:10 -0800, Justin Zygmont wrote:
sounds like the GUI tools arent using the UPG scheme where each user is in their own group, not sure if it is a bug, but it seems like it probably is. It just goes to show the command line is the best way to use an OS.
I really hate reading that. There are crap CLI tools as well as GUI tools. It's not a case that GUI or CLI is better or worse than each other, but that some programmers are.
CLI tools are heavily dependent on good documentation. Some documentation is absolutely crap, if there even is any.
GUI tools can be intuitively designed, if the designer has any idea about creating good GUIs.
Both problems rest squarely on the shoulders of who programmed them, not the GUI or CLI.
-
Craig White -
Dave Brown -
James Wilkinson -
Justin Zygmont -
Kanwar Ranbir Sandhu -
Robin Laing -
Tim