Bug 459825 - groupmems call segfaults for unknown reason.
groupmems call segfaults for unknown reason.
Status: CLOSED DUPLICATE of bug 459817
Product: Fedora
Classification: Fedora
Component: shadow-utils (Show other bugs)
9
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Vrabec
Fedora Extras Quality Assurance
http://pastebin.ca/1181765
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-22 14:09 EDT by Chris Goetschius
Modified: 2008-09-02 05:03 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-02 05:03:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Goetschius 2008-08-22 14:09:00 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 ?

How reproducible:
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
  
Actual results:
Failed to add frankl to Domain Users. dmesg lists the segfault
Aug 22 13:59:50 pdc kernel: groupmems[2687]: segfault at 1f6 ip 0096a71b sp bfca3b7c error 4 in libc-2.8.so[8f5000+163000]
Aug 22 13:59:51 pdc kernel: groupmems[2695]: segfault at 355 ip 0096a71b sp bf818efc error 4 in libc-2.8.so[8f5000+163000]
Aug 22 13:59:51 pdc kernel: groupmems[2698]: segfault at 354 ip 0096a743 sp bfb4221c error 4 in libc-2.8.so[8f5000+163000]

Expected results:
user is added to the group without issue

Additional info:
Domain Users is mapped to users
Domain Admins is mapped to administration
Comment 1 Chris Goetschius 2008-08-22 14:14:49 EDT
   1.
      (gdb) backtrace
   2.
      #0  0x0096a71b in strlen () from /lib/libc.so.6
   3.
      #1  0x0096a475 in __strdup (s=<value optimized out>) at strdup.c:42
   4.
      #2  0x0804a152 in __gr_dup (grent=0x8e7ff18) at groupmem.c:28
   5.
      #3  0x0804a91b in commonio_update (db=0x804e8a0, eptr=0x8e7ff18) at commonio.c:813
   6.
      #4  0x08049fd9 in gr_update (gr=0x8e7ff18) at groupio.c:130
   7.
      #5  0x08049662 in main (argc=Cannot access memory at address 0x1
   8.
      ) at groupmems.c:287
Comment 2 Peter Vrabec 2008-08-25 11:23:04 EDT
Chris, 

is frankl a samba user? 
are users in local db(/etc/group)?
Comment 3 Chris Goetschius 2008-08-25 11:37:02 EDT
Yes. This happened in a script:
{{{
#!/bin/bash
if [ -z "$1" -o -z "$2" ]; then
        echo usage: $0 username password
        exit
fi
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_________
mkdir /var/lib/samba/profiles/$1
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
}}}
Comment 4 Chris Goetschius 2008-08-25 11:38:36 EDT
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.
Comment 5 Peter Vrabec 2008-08-25 12:28:07 EDT
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.
Comment 6 Chris Goetschius 2008-08-25 12:39:33 EDT
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
Comment 7 Peter Vrabec 2008-08-28 09:05:43 EDT
can you try:
http://people.redhat.com/pvrabec/rpms/shadow-utils-4.1.2-5.fc9.src.rpm

I hope it helps also with #459817
Comment 8 Chris Goetschius 2008-08-28 10:44:34 EDT
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.
Comment 9 Peter Vrabec 2008-09-02 05:03:50 EDT

*** This bug has been marked as a duplicate of bug 459817 ***

Note You need to log in before you can comment on or make changes to this bug.