LTC 242 Hardware Environment:ia32Software Environment:Redhat 7.1 full installSteps to Reproduce:1. Add user foo using 'useradd foo'. This will create a user named foo and also create an initial group for user foo named foo.2. Modify user account using 'usermod -g bar foo' to change foo's initial group to bar. 3. Delete user account using 'userdel foo'Actual Results:User foo is removed from /etc/passwd and from the group bar in /etc/group file,but group foo is left dangling. Any attempt to add user foo in the future via the useradd command is foiled due to pre-existance of the foo group.Expected Results:Most implementations of useradd do not create groups by default, since this step is redundant with the -g option.Contact Information:Arnold Haydenhaydena.com(512)838-3302Additional Information:This "feature"'s inconsistency breaks several test cases in the LSB Testsuite. It is also undocumented in the manpage for useradd except for the obscure warning "This version of useradd was modified by Red Hat to suit Red Hat user/group convention." ------- Additional Comments From Khoa Huynh(khoa.com) 2001-08-28 20:15 ------- Wow! There is NO carriage return in the bug description! Kyle -- would you take this problem for us? Thanks.... ------- Additional Comments From Kyle Grieser(yuf.com) 2001-08-29 13:34 ------- Hardware Environment:ia32Software Environment:Redhat 7.1 full installSteps to Reproduce:1. Add user foo using 'useradd foo'. This will create a user named foo and also create an initial group for user foo named foo.2. Modify user account using 'usermod -g bar foo' to change foo's initial group to bar. 3. Delete user account using 'userdel foo'Actual Results:User foo is removed from /etc/passwd and from the group bar in /etc/group file,but group foo is left dangling. Any attempt to add user foo in the future via the useradd command is foiled due to pre-existance of the foo group.Expected Results:Most implementations of useradd do not create groups by default, since this step is redundant with the -g option. Contact Information:Arnold Haydenhaydena.com(512)838-3302 Additional Information:This "feature"'s inconsistency breaks several test cases in the LSB Testsuite. It is also undocumented in the manpage for useradd except for the obscure warning "This version of useradd was modified by Red Hat to suit Red Hat user/group convention." ------- Additional Comments From David Wilder(wilder.com) 2001-09-06 20:04 ------- This problem is the results of changes that RedHat make to the useradd, usermod, and userdel commands when they implemented their user private group convention. More on this can be found at:http://www.europe.redhat.com/documentation/rhl6.1/ref-guide-en/s1-sysadmin-us r-grps.php3#S2-SYSADMIN-PRIV-GROUPS The reported problem is that the userdel command fails to locate and delete the user private group when removing a user. The problem only occurs when the users initial group has previously been changes to a group other than the user's private group. When I investigated I found that the code to remove this dangling group was already in the userdel command however for the code to work it required that the /etc/login.defs file contain the line: USERGROUPS_ENAB yes This line is missing from the distribution file. I added the line and it seams to fix the problem. The next step is to investigate why this line was missing from the login.defs file and make sure that adding the line won't break anything else. ------- Additional Comments From David Wilder(wilder.com) 2001-09-12 16:50 ------- Setting USERGROUPS_ENAB breaks other functions. Will investigate further. ------- Additional Comments From David Wilder(wilder.com) 2001-09-12 18:53 ------- The submitter is testing for Linux Standard Base V1 compliance of the useradd/userdel commands. The test they are using is failing due to changes that RedHat made to these commands when they implemented their user private group convention. The change made to useradd/userdel by RedHat breaks the Linux Standard Base (LSB) V1 specification for the behaviour of the useradd command. According to the LSB the command should set the initial group of the new user to a default gid of 1 (unless the -g option is used). RedHats version of the command will results in a new group being created with a new gid and setting the new users initial group to this new gid. It may be possible to change the useradd code so that the specific test will not fail by correctly removing the private group with the useradd command. However this will not result in compliance to the LSB specification. I don't know if RedHat's release has a requirement to pass LSB testing. I spoke to Ken Hake about this issue. He will present the problem to RedHat and ask for a response. ------- Additional Comments From David Wilder(wilder.com) 2001-09-19 17:19 ------- Enhancements that Redhat has made to the useradd command results in the command not passing LSB testing. I feel that the command not simply broken but is not conforming to the LSB V1. This is a Redhat issue therefore I am transferring the bug to gjohnson.com for further disposition. ------- Additional Comments From Khoa Huynh(khoa.com) 2001-09-25 15:45 ------- Glen -- please submit this to Red Hat and ask them if they choose to comply to the LSB standard for the useradd/userdel commands. Thanks.
Assigning to shadow-utils. Please take care to assign bugs to the correct component - thanks!
The LSB is changing the standard to allow this behavior.