Bug 54109

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.