RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 987536 - sssd_be segfaults on sudo usage
Summary: sssd_be segfaults on sudo usage
Keywords:
Status: CLOSED DUPLICATE of bug 963235
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.4
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-23 15:30 UTC by mleary
Modified: 2013-08-08 08:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-08 08:18:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description mleary 2013-07-23 15:30:27 UTC 
Description of problem:

SSSD is configured with ldap/kerberos.  Functions normally, except running the sudo command causes sssd_be to crash.  Most of the time the processes is automatically relaunched and sssd recovers.  Occasionally however, sssd does not recover and needs to be manually restarted before users can login again.  Sudo is actually successful despite the crash.

Version-Release number of selected component (if applicable):

1.9.2-82.7.el6_4.x86_64

How reproducible:

Apparently something specific to our sssd configuration causes this, but I am not sure what.  We are authenticating against an AD domain using ldap for directory services and krb5 for the actual auth.  We do not have this issue with nslcd/pam.

coredump has potentially sensitive information, so I'll send it privately but do not want to attach here.
Comment 1 Jakub Hrozek 2013-07-23 15:37:00 UTC 
Thank you very much for the bug report. We are not currently aware of any sssd_be crash related to sudo. Feel free to send the corefile to my address (jhrozek) and copy Pavel Brezina (pbrezina).
Comment 2 Jakub Hrozek 2013-07-23 15:41:08 UTC 
Also would you mind attaching the logs when you send the core file? To generate the logs, put "debug_level=10" into the [sudo] and [domain] sections of the sssd.conf, restart the sssd, re-run the crasher case and then attach the contents of /var/log/sssd/

Thank you!
Comment 4 Pavel Březina 2013-07-24 11:08:23 UTC 
Hi,
thank you for the corefile. Unfortunately, it is not clear why SSSD gets to the state where it crashes.

Can you also send us the logs and possibly sssd.conf please?
Is this always reproducible or does this happen only sporadically?
Comment 5 Jakub Hrozek 2013-08-01 10:05:06 UTC 
Hi, any luck getting the log files Pavel requested? Since you were able to reproduce the problem in-house, the log files would be a great help for us..
Comment 6 mleary 2013-08-01 14:59:24 UTC 
Sorry, I'll email the log entries today.  This does happen sporadically, I'd say maybe 10% of the time we run sudo.  I should also mention we are not using SSSD for our sudo database, we are using the standard sudoers file.  However there are groups in sudoers that come from ldap via SSSD.
Comment 7 Jakub Hrozek 2013-08-02 10:53:37 UTC 
(In reply to mleary from comment #6)
> Sorry, I'll email the log entries today.  This does happen sporadically, I'd
> say maybe 10% of the time we run sudo.  

Right, according to Pavel's investigation of the core file, the bug is actually a use-after-free problem, so chances are that the contents of the memory are still available despite beeing freed most of the time.

> I should also mention we are not
> using SSSD for our sudo database, we are using the standard sudoers file. 
> However there are groups in sudoers that come from ldap via SSSD.

Yep, the crash seems to have happened in the nested group processing.

Thanks for the logs, either me or Pavel would take a look..
Comment 8 Jakub Hrozek 2013-08-06 20:15:48 UTC 
Hello Mark,

we believe we found the culprit. There was a use-after-free situation in one of the less probable branches of the nested group processing. I built test packages which are the same as the 6.4 ones, just with the additional fix on top. Can you try them out if you have a moment?

The builds are here:
http://jhrozek.fedorapeople.org/sssd-test-builds/sssd-nested-group-crash/

btw this is most likely the same issue as the one tracked in #963235
Comment 9 Jakub Hrozek 2013-08-08 08:18:18 UTC 
Marking this bug as duplicate of #963235 as that one has more complete information.

*** This bug has been marked as a duplicate of bug 963235 ***
Note You need to log in before you can comment on or make changes to this bug.