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 1792331 - sssd_be crashes when krb5_realm and krb5_server is omitted and auth_provider is krb5
Summary: sssd_be crashes when krb5_realm and krb5_server is omitted and auth_provider ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.2
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: 8.2
Assignee: Alexey Tikhonov
QA Contact: sssd-qe
URL:
Whiteboard: sync-to-jira
: 1793303 1796044 1796470 1798492 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-17 14:23 UTC by Niranjan Mallapadi Raghavender
Modified: 2023-03-31 13:06 UTC (History)
12 users (show)

Fixed In Version: sssd-2.2.3-16.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:56:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 5096 0 None closed util/sss_ptr_hash.c: potential double free in `sss_ptr_hash_delete_cb()` 2021-02-16 13:01:16 UTC
Red Hat Issue Tracker RHELPLAN-33255 0 None None None 2023-03-31 13:03:19 UTC
Red Hat Issue Tracker SSSD-1944 0 None None None 2023-03-31 13:06:03 UTC
Red Hat Product Errata RHBA-2020:1863 0 None None None 2020-04-28 16:56:40 UTC

Description Niranjan Mallapadi Raghavender 2020-01-17 14:23:03 UTC 
Description of problem:

sssd_be crashes when auth_provider is set to krb5 but no krb5_realm and krb5_server are mentioned in sssd.conf 



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


How reproducible:


Steps to Reproduce:
1. configure sssd.conf as below 
[sssd]
config_file_version = 2
services = nss, pam
domains = example1

[domain/example1]
ldap_search_base = dc=example,dc=test
id_provider = ldap
auth_provider = krb5
ldap_user_home_directory = /home/%u
ldap_uri = ldaps://vm-idm-033.lab.eng.pnq.redhat.com
ldap_tls_cacert = /etc/openldap/cacerts/cacert.pem
use_fully_qualified_names = True
debug_level = 9


2.Restart sssd


Actual results:
sssd crashes

Expected results:
sssd should fail to start but not crash 

Additional info:
Comment 1 Niranjan Mallapadi Raghavender 2020-01-17 14:26:57 UTC 
Backtrace from the coredump

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f974c01cb25 in __GI_abort () at abort.c:79
#2  0x00007f974c92cde0 in talloc_abort (reason=0x7f974c93aa88 "Bad talloc magic value - unknown value") at ../../talloc.c:505
#3  0x00007f974c92cf2a in talloc_abort_unknown_value () at ../../talloc.c:534
#4  talloc_chunk_from_ptr (ptr=0x5651ebfec0e0) at ../../talloc.c:534
#5  __talloc_get_name (ptr=0x5651ebfec0e0) at ../../talloc.c:1559
#6  talloc_check_name (ptr=ptr@entry=0x5651ebfec0e0, name=name@entry=0x7f974fba84e5 "struct sss_ptr_hash_value") at ../../talloc.c:1582
#7  0x00007f974fb8d731 in sss_ptr_hash_check_type (ptr=0x5651ebfec0e0, type=0x7f974fba84e5 "struct sss_ptr_hash_value") at src/util/sss_ptr_hash.c:31
#8  0x00007f974fb8d80d in sss_ptr_hash_lookup_internal (table=<optimized out>, key=key@entry=0x5651ebfcd7a0 "sssd.nss") at src/util/sss_ptr_hash.c:273
#9  0x00007f974fb8dc62 in _sss_ptr_hash_lookup (table=<optimized out>, key=key@entry=0x5651ebfcd7a0 "sssd.nss", type=type@entry=0x7f974cf8316f "struct sbus_connection") at src/util/sss_ptr_hash.c:286
#10 0x00007f974cf7f33f in sbus_server_connection_has_name (server=0x5651ebf931f0, name=0x5651ebfcd7a0 "sssd.nss", conn=0x5651ebfd1120) at src/sbus/server/sbus_server_match.c:439
#11 sbus_server_matchmaker (server=server@entry=0x5651ebf931f0, conn=conn@entry=0x0, avoid_name=0x5651ebfcd7a0 "sssd.nss", message=message@entry=0x5651ebf98dd0) at src/sbus/server/sbus_server_match.c:439
#12 0x00007f974cf7f69f in sbus_server_name_owner_changed (server=0x5651ebf931f0, name=<optimized out>, new_owner=<optimized out>, old_owner=<optimized out>) at src/sbus/server/sbus_server.c:536
#13 0x00007f974fb8d62f in sss_ptr_hash_delete_cb (item=0x5651ebfb5a70, deltype=HASH_ENTRY_DESTROY, pvt=<optimized out>) at src/util/sss_ptr_hash.c:162
#14 0x00007f974cd54d7d in hash_delete (table=table@entry=0x5651ebf68b90, key=key@entry=0x7fff20704520) at dhash/dhash.c:1077
#15 0x00007f974fb8dd86 in sss_ptr_hash_delete (free_value=false, key=0x5651ebfcd720 "sssd.nss", table=0x5651ebf68b90) at src/util/sss_ptr_hash.c:348
#16 sss_ptr_hash_delete (table=0x5651ebf68b90, key=0x5651ebfcd720 "sssd.nss", free_value=<optimized out>) at src/util/sss_ptr_hash.c:323
#17 0x00007f974fb8de31 in sss_ptr_hash_spy_destructor (spy=spy@entry=0x5651ebfca2a0) at src/util/sss_ptr_hash.c:64
#18 0x00007f974c933c50 in _tc_free_internal (location=0x7f974cf82d78 "src/sbus/connection/sbus_connection.c:438", tc=0x5651ebfca240) at ../../talloc.c:1157
#19 _tc_free_children_internal (location=<optimized out>, ptr=<optimized out>, tc=<optimized out>) at ../../talloc.c:1666
#20 talloc_free_children (ptr=<optimized out>) at ../../talloc.c:1712
#21 0x00007f974c92f034 in _tc_free_internal (location=0x7f974cf82d78 "src/sbus/connection/sbus_connection.c:438", tc=0x5651ec079880) at ../../talloc.c:1183
#22 _talloc_free_internal (location=0x7f974cf82d78 "src/sbus/connection/sbus_connection.c:438", ptr=0x5651ec0798e0) at ../../talloc.c:1247
#23 _talloc_free (ptr=0x5651ec0798e0, location=0x7f974cf82d78 "src/sbus/connection/sbus_connection.c:438") at ../../talloc.c:1789
#24 0x00007f974cb4b3b9 in tevent_common_invoke_timer_handler (te=te@entry=0x5651ebfb3be0, current_time=..., removed=removed@entry=0x0) at ../../tevent_timed.c:370
#25 0x00007f974cb4b55e in tevent_common_loop_timer_delay (ev=ev@entry=0x5651ebf6c210) at ../../tevent_timed.c:442
#26 0x00007f974cb4c7ab in epoll_event_loop_once (ev=0x5651ebf6c210, location=<optimized out>) at ../../tevent_epoll.c:922
#27 0x00007f974cb4a99b in std_event_loop_once (ev=0x5651ebf6c210, location=0x7f974fba3659 "src/util/server.c:719") at ../../tevent_standard.c:110
#28 0x00007f974cb45b15 in _tevent_loop_once (ev=ev@entry=0x5651ebf6c210, location=location@entry=0x7f974fba3659 "src/util/server.c:719") at ../../tevent.c:772
#29 0x00007f974cb45dbb in tevent_common_loop_wait (ev=0x5651ebf6c210, location=0x7f974fba3659 "src/util/server.c:719") at ../../tevent.c:895
#30 0x00007f974cb4a92b in std_event_loop_wait (ev=0x5651ebf6c210, location=0x7f974fba3659 "src/util/server.c:719") at ../../tevent_standard.c:141
#31 0x00007f974fb81927 in server_loop (main_ctx=0x5651ebf4d0c0) at src/util/server.c:719
#32 0x00005651ea39e62b in main (argc=8, argv=<optimized out>) at src/providers/data_provider_be.c:743
Comment 2 Alexey Tikhonov 2020-01-17 15:21:11 UTC 
Additional info shared by Niranjan: "I can see the crash even on sssd-2.2.2-1.el8.x86_64"

Well, it seems:
 - bug was there till sssd-2.2.3-1 where it was accidentally fixed with f95db37aa8486304d0569d12a876b1c74ee1b0d1 that introduced bz 1783190
 - and then this bug was introduced back in sssd-2.2.3-9 with 26e33b1984cce3549df170f58f8221201ad54cfd while fixing bz 1783190


Niranjan, would it be please possible to verify that (2.2.3-1 and 2.2.3-8) *are NOT* affected and (2.2.2-1 and 2.2.3-9) *are* affected?
Comment 10 Alexey Tikhonov 2020-01-21 09:45:02 UTC 
*** Bug 1793303 has been marked as a duplicate of this bug. ***
Comment 14 Alexey Tikhonov 2020-01-29 13:57:25 UTC 
*** Bug 1796044 has been marked as a duplicate of this bug. ***
Comment 16 Alexey Tikhonov 2020-01-30 11:56:26 UTC 
PR: https://github.com/SSSD/sssd/pull/977
Comment 17 Alexey Tikhonov 2020-01-30 17:31:39 UTC 
*** Bug 1796470 has been marked as a duplicate of this bug. ***
Comment 18 Alexey Tikhonov 2020-02-11 11:52:29 UTC 
*** Bug 1798492 has been marked as a duplicate of this bug. ***
Comment 21 Alexey Tikhonov 2020-02-17 10:54:12 UTC 
master:
  * faa5dbf6f716bd4ac0a3020a28a1ee6fbf74654a
  * adc7730a4e1b9721c93863a1b283457e9c02a3c5
  * d0eb88089b059bfe2da3bd1a3797b89d69119c29
  * 8cc2ce4e9060a71d441a377008fb2f567baa5d92
  * 4bc0c2c7833dd643fc1137daf6519670c05c3736
  * 0bb1289252eec972ea26721a92adc7db47383f76
  * 88b23bf50dd1c12413f3314639de2c3909bd9098
Comment 26 Niranjan Mallapadi Raghavender 2020-02-21 09:52:11 UTC 
Versions:

sssd-krb5-common-2.2.3-16.el8.x86_64
sssd-winbind-idmap-2.2.3-16.el8.x86_64
sssd-ldap-2.2.3-16.el8.x86_64
sssd-kcm-2.2.3-16.el8.x86_64
sssd-common-pac-2.2.3-16.el8.x86_64
sssd-2.2.3-16.el8.x86_64
python3-sssdconfig-2.2.3-16.el8.noarch
sssd-common-2.2.3-16.el8.x86_64
sssd-ad-2.2.3-16.el8.x86_64
sssd-proxy-2.2.3-16.el8.x86_64
sssd-tools-2.2.3-16.el8.x86_64
sssd-nfs-idmap-2.2.3-14.el8.x86_64
sssd-client-2.2.3-16.el8.x86_64
sssd-krb5-2.2.3-16.el8.x86_64
sssd-dbus-2.2.3-16.el8.x86_64
sssd-ipa-2.2.3-16.el8.x86_64


cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = example1

[domain/example1]
ldap_search_base = dc=example,dc=test
id_provider = ldap
auth_provider = krb5
ldap_user_home_directory = /home/%u
ldap_uri = ldaps://vm-10-0-153-149.hosted.upshift.rdu2.redhat.com
ldap_tls_cacert = /etc/openldap/cacerts/cacert.pem
use_fully_qualified_names = False
debug_level = 9
ldap_sasl_mech = GSSAPI


Restart sssd
[root@vm-10-0-154-50 yum.repos.d]# systemctl restart sssd
Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.

As seen above sssd doesn't crash but since the configuration is missing must statements
required for auth_provider=krb5 namely krb5_server and krb5_realm , sssd fails to start. But it doesn't
crash.
Comment 28 errata-xmlrpc 2020-04-28 16:56:29 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1863
Note You need to log in before you can comment on or make changes to this bug.