Red Hat Bugzilla – Bug 459825
groupmems call segfaults for unknown reason.
Last modified: 2008-09-02 05:03:50 EDT
Description of problem:
/usr/sbin/groupmems -a frankl -g users
casuses a segfault - error 4 libc-2.8
Version-Release number of selected component (if applicable):
System Management Commands 04/03/2008 ?
The setup is probably key to the actual error. The OS is in a virtual machine on a Vista64 host. VirtualPC is the program used to host. The option noreplace-paravirt is added to kernel boot parameters. The machine has samba running on it and is designated as a primary domain controller.
Steps to Reproduce:
1. net user add frankl
2. net password frankl password
3. net rpc group addmem "Domain Admins" frankl
4. net rpc group addmem "Domain Users" frankl
Failed to add frankl to Domain Users. dmesg lists the segfault
Aug 22 13:59:50 pdc kernel: groupmems: segfault at 1f6 ip 0096a71b sp bfca3b7c error 4 in libc-2.8.so[8f5000+163000]
Aug 22 13:59:51 pdc kernel: groupmems: segfault at 355 ip 0096a71b sp bf818efc error 4 in libc-2.8.so[8f5000+163000]
Aug 22 13:59:51 pdc kernel: groupmems: segfault at 354 ip 0096a743 sp bfb4221c error 4 in libc-2.8.so[8f5000+163000]
user is added to the group without issue
Domain Users is mapped to users
Domain Admins is mapped to administration
#0 0x0096a71b in strlen () from /lib/libc.so.6
#1 0x0096a475 in __strdup (s=<value optimized out>) at strdup.c:42
#2 0x0804a152 in __gr_dup (grent=0x8e7ff18) at groupmem.c:28
#3 0x0804a91b in commonio_update (db=0x804e8a0, eptr=0x8e7ff18) at commonio.c:813
#4 0x08049fd9 in gr_update (gr=0x8e7ff18) at groupio.c:130
#5 0x08049662 in main (argc=Cannot access memory at address 0x1
) at groupmems.c:287
is frankl a samba user?
are users in local db(/etc/group)?
Yes. This happened in a script:
if [ -z "$1" -o -z "$2" ]; then
echo usage: $0 username password
net rpc user add $1 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net rpc password $1 $2 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net rpc group addmem "Domain Admins" $1 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net rpc group addmem "Domain Users" $1 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net rpc group addmem "BCAdmin" $1 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net rpc group addmem "BCTrusted" $1 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net rpc group addmem "BCSales" $1 -S pdc -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
net sam set pwdmustchangenow $1 no -Uroot%_________INSERT_ROOT_PASSWORD_HERE_________
chown -R $1:$1 /var/lib/samba/profiles/$1
chmod -R 0700 /var/lib/samba/profiles/$1
The samba settings for those calls are:
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -a -G %g %u
delete user from group script = /usr/sbin/groupmod -g %g -d %u
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null %u
oh - those settings aren't correct. Those are the ones that I'm using now to workaround the issue. The add user to group script was using groupmems before.
which package provides this script?
I don't understand the problem now. But one thing is clear to me. groupmems checks if user us in local db, but usermod doesn't. shadow-utils tools are not intended to work with remote user accounts like NIS/samba/LDAP.
The script above is a script I made to make user accounts on the machine that are also part of the domain. The call net rpc group addmem calls the script in the samba confic labled add user to group. net rpc user add calls the script add user script. The user is in the local user db, since they are added at the first net rpc user add call within the script.
Basically - If I do the following after deleting the user the error occurs (without using a script).
/usr/sbin/useradd -m frankl
/usr/sbin/groupmems -a frankl -g users
can you try:
I hope it helps also with #459817
It's in a production environment, so testing will have to wait until a time where none of the systems are in use. That's not going to happen until sometime next week. I looked at the other ticket though (#459817), and they definitely seem related. I would even go so far as calling this ticket a duplicate of #459817.
*** This bug has been marked as a duplicate of bug 459817 ***