1667252 – crash when requesting extra attributes

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 1667252 - crash when requesting extra attributes

Summary: crash when requesting extra attributes

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	sssd
Sub Component:
Version:	8.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	8.0
Assignee:	Pavel Březina
QA Contact:	sssd-qe
Docs Contact:
URL:
Whiteboard:
Depends On:	1682305
Blocks:
TreeView+	depends on / blocked

Reported:	2019-01-17 20:51 UTC by Jakub Hrozek
Modified:	2020-05-02 19:05 UTC (History)
CC List:	10 users (show)
Fixed In Version:	sssd-2.1.0-1.el8
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2019-11-05 22:34:01 UTC
Type:	---
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	SSSD sssd issues 4906	0	None	closed	crash when requesting extra attributes	2021-02-16 15:51:08 UTC
Red Hat Product Errata	RHSA-2019:3651	0	None	None	None	2019-11-05 22:34:15 UTC

Description Jakub Hrozek 2019-01-17 20:51:25 UTC

This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3921

Copying from https://github.com/SSSD/sssd/pull/735:
When we open container for DBUS_TYPE_DICT_ENTRY, dbus expects the
signature to be NULL.

Reproducer:

    Setup custom attributes

[ifp]
user_attributes = +test

[domain/ldap.vm]
...
ldap_user_extra_attrs = test:homeDirectory

    Run SSSD and require those attributes for example with

sssctl user-checks user-1

    SSSD will crash without the patch

Comment 1 Jakub Hrozek 2019-01-17 20:52:36 UTC

* master: bc1e8ffd5cca74aa8408c1c6bce0a3cf42a0974b

Comment 7 Niranjan Mallapadi Raghavender 2019-08-29 12:27:34 UTC

Version:

sssd-nfs-idmap-2.0.0-1.el8.x86_64
sssd-client-2.0.0-1.el8.x86_64
sssd-common-pac-2.0.0-1.el8.x86_64
sssd-proxy-2.0.0-1.el8.x86_64
sssd-tools-2.0.0-1.el8.x86_64
python3-sssdconfig-2.0.0-1.el8.noarch
sssd-krb5-common-2.0.0-1.el8.x86_64
sssd-ad-2.0.0-1.el8.x86_64
sssd-ldap-2.0.0-1.el8.x86_64
sssd-2.0.0-1.el8.x86_64
sssd-common-2.0.0-1.el8.x86_64
sssd-krb5-2.0.0-1.el8.x86_64
sssd-ipa-2.0.0-1.el8.x86_64
sssd-dbus-2.0.0-1.el8.x86_64


I am trying to reproduce the issue on 8.1 with above installed versions. 

[sssd]
config_file_version = 2
services = nss, pam, ifp
domains = example1

[domain/example1]
ldap_search_base = dc=example,dc=test
id_provider = ldap
auth_provider = ldap
ldap_user_home_directory = /export/home/%u
ldap_uri = ldaps://cdardine.testrelm.test
ldap_tls_cacert = /etc/openldap/cacerts/cacert.pem
use_fully_qualified_names = True
debug_level = 9
ldap_user_extra_attrs = test:blablabla

[ifp]
user_attributes = +test

when i run sssctl user-check foo1@example1, i don't see any sssd crash. 

[root@katherine ~]# sssctl user-checks foo1@example1
user: foo1@example1
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: foo1@example1
 - user id: 14583101
 - group id: 14564100
 - gecos: foo1 User
 - home directory: /
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: foo1@example1
 - uidNumber: 14583101
 - gidNumber: 14564100
 - gecos: foo1 User
 - homeDirectory: not set
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Success

Can you let me know if there is anything i am missing ,

Comment 8 Pavel Březina 2019-08-30 08:42:36 UTC

I believe the extra attributes must actually exist. So instead of 'blablabla' which you would need to extend the ldap schema in order to create it on the user object, use 'homeDirectory' which already exist.

Comment 9 Niranjan Mallapadi Raghavender 2019-08-30 08:56:11 UTC

Even when i set with attribute of Home Directory which actually exists:

[root@katherine ~]# ldapsearch -x -b "dc=example,dc=test" -D "cn=Directory Manager" -w Secret123 -h cdardine.testrelm.test  uid=foo1 homeDirectory -LLL
dn: uid=foo1,ou=People,dc=example,dc=test
homeDirectory: /home/foo1
[root@katherine ~]# sssctl user-checks foo1@example1
user: foo1@example1
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: foo1@example1
 - user id: 14583101
 - group id: 14564100
 - gecos: foo1 User
 - home directory: /
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: foo1@example1
 - uidNumber: 14583101
 - gidNumber: 14564100
 - gecos: foo1 User
 - homeDirectory: not set
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -


I didn't notice any crash

Comment 11 Niranjan Mallapadi Raghavender 2019-09-03 10:11:20 UTC

Reproducing the issue:
======================

Red Hat Enterprise Linux release 8.0 (Ootpa)

[root@dell-r730-015 ~]# rpm -qa | grep sss
sssd-common-pac-2.0.0-43.el8.x86_64
sssd-ldap-2.0.0-43.el8.x86_64
python3-sssdconfig-2.0.0-43.el8.noarch
sssd-tools-2.0.0-43.el8.x86_64
libsss_idmap-2.0.0-43.el8.x86_64
libsss_autofs-2.0.0-43.el8.x86_64
libsss_certmap-2.0.0-43.el8.x86_64
sssd-nfs-idmap-2.0.0-43.el8.x86_64
sssd-kcm-2.0.0-43.el8.x86_64
libsss_nss_idmap-2.0.0-43.el8.x86_64
sssd-krb5-2.0.0-43.el8.x86_64
sssd-proxy-2.0.0-43.el8.x86_64
sssd-2.0.0-43.el8.x86_64
sssd-dbus-2.0.0-43.el8.x86_64
python3-sss-2.0.0-43.el8.x86_64
sssd-krb5-common-2.0.0-43.el8.x86_64
sssd-ad-2.0.0-43.el8.x86_64
sssd-ipa-2.0.0-43.el8.x86_64
libsss_simpleifp-2.0.0-43.el8.x86_64
sssd-client-2.0.0-43.el8.x86_64
sssd-common-2.0.0-43.el8.x86_64
libsss_sudo-2.0.0-43.el8.x86_64

Configure sssd.conf as shown below:
[sssd]
config_file_version = 2
services = nss, pam, ifp
domains = example1

[domain/example1]
ldap_search_base = dc=example,dc=test
id_provider = ldap
auth_provider = ldap
ldap_user_home_directory = /home/%u
ldap_uri = ldaps://dell-r730-015.dsal.lab.eng.rdu2.redhat.com
ldap_tls_cacert = /etc/openldap/cacerts/cacert.pem
use_fully_qualified_names = True
debug_level = 9
ldap_user_extra_attrs = test:homeDirectory

[ifp]
user_attributes = +test

[root@dell-r730-015 ~]# id foo1@example1
uid=14583101(foo1@example1) gid=14564100(ldapusers@example1) groups=14564100(ldapusers@example1)

User's foo entry in cache 

# record 2
dn: name=foo1@example1,cn=users,cn=example1,cn=sysdb
createTimestamp: 1567504649
fullName: foo1 User
gecos: foo1 User
gidNumber: 14564100
loginShell: /bin/bash
name: foo1@example1
objectCategory: user
uidNumber: 14583101
originalDN: uid=foo1,ou=People,dc=example,dc=test
originalModifyTimestamp: 20190903095525Z
entryUSN: 20190903095525Z
mail: foo1
test: /home/foo1
nameAlias: foo1@example1
isPosix: TRUE
lastUpdate: 1567504649
dataExpireTimestamp: 1567510049
initgrExpireTimestamp: 1567510049
distinguishedName: name=foo1@example1,cn=users,cn=example1,cn=sysdb

[root@dell-r730-015 ~]# sssctl user-checks foo1@example1
user: foo1@example1
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: foo1@example1
 - user id: 14583101
 - group id: 14564100
 - gecos: foo1 User
 - home directory:
 - shell: /bin/bash

InfoPipe operation failed. Check that SSSD is running and the InfoPipe responder is enabled. Make sure 'ifp' is listed in the 'services' option in sssd.conf.InfoPipe User lookup with [foo1@example1] failed.
testing pam_acct_mgmt

pam_acct_mgmt: Success   

PAM Environment:
 - no env -


sssd-ifp coredumps :

Sep 03 05:57:29 dell-r730-015.dsal.lab.eng.rdu2.redhat.com systemd-coredump[28368]: Process 28356 (sssd_ifp) of user 0 dumped core.

Stack trace of thread 28356:
#0  0x00007f5e6930593f raise (libc.so.6)
#1  0x00007f5e692efc95 abort (libc.so.6)
#2  0x00007f5e696a282d _dbus_abort.cold.0 (libdbus-1.so.3)
#3  0x00007f5e696c4c20 _dbus_warn_check_failed (libdbus-1.so.3)
#4  0x00007f5e696b654f dbus_message_iter_open_container (libdbus-1.so.3)
#5  0x00007f5e69f316c7 sbus_copy_iterator_value.part.0 (libsss_sbus.so)
#6  0x00007f5e69f316d6 sbus_copy_iterator_value.part.0 (libsss_sbus.so)
#7  0x00007f5e69f316d6 sbus_copy_iterator_value.part.0 (libsss_sbus.so)
#8  0x00007f5e69f326c8 sbus_properties_getall_done (libsss_sbus.so)
#9  0x00007f5e69b05bd9 tevent_common_invoke_timer_handler (libtevent.so.0)
#10 0x00007f5e69b05d7e tevent_common_loop_timer_delay (libtevent.so.0)
#11 0x00007f5e69b07219 epoll_event_loop_once (libtevent.so.0)
#12 0x00007f5e69b051bb std_event_loop_once (libtevent.so.0)
#13 0x00007f5e69b00395 _tevent_loop_once (libtevent.so.0)
#14 0x00007f5e69b0063b tevent_common_loop_wait (libtevent.so.0)
#15 0x00007f5e69b0514b std_event_loop_wait (libtevent.so.0)
#16 0x00007f5e6cfbaa07 server_loop (libsss_util.so)
#17 0x000055c77c9cf24d main (sssd_ifp)
#18 0x00007f5e692f1813 __libc_start_main (libc.so.6)
#19 0x000055c77c9cf2de _start (sssd_ifp)


Update sssd to latest from 8.1:

libsss_certmap-2.2.0-16.el8.x86_64
libsss_autofs-2.0.0-43.el8.x86_64
sssd-common-2.2.0-16.el8.x86_64
sssd-ad-2.2.0-16.el8.x86_64
sssd-proxy-2.2.0-16.el8.x86_64
sssd-tools-2.2.0-16.el8.x86_64
sssd-nfs-idmap-2.0.0-43.el8.x86_64
libsss_nss_idmap-2.0.0-43.el8.x86_64
libsss_idmap-2.2.0-16.el8.x86_64
sssd-client-2.2.0-16.el8.x86_64
sssd-krb5-common-2.2.0-16.el8.x86_64
sssd-dbus-2.2.0-16.el8.x86_64
sssd-krb5-2.2.0-16.el8.x86_64
python3-sss-2.2.0-16.el8.x86_64
sssd-2.2.0-16.el8.x86_64
libsss_simpleifp-2.2.0-16.el8.x86_64
python3-sssdconfig-2.2.0-16.el8.noarch
libsss_sudo-2.0.0-43.el8.x86_64
sssd-common-pac-2.2.0-16.el8.x86_64
sssd-ldap-2.2.0-16.el8.x86_64
sssd-ipa-2.2.0-16.el8.x86_64
sssd-kcm-2.2.0-16.el8.x86_64

[root@dell-r730-015 yum.repos.d]# sssctl user-checks foo1@example1
user: foo1@example1
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: foo1@example1
 - user id: 14583101
 - group id: 14564100
 - gecos: foo1 User
 - home directory: 
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: foo1@example1
 - uidNumber: 14583101
 - gidNumber: 14564100
 - gecos: foo1 User
 - homeDirectory: not set
 - loginShell: /bin/bash
 - test: /home/foo1

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -

● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-09-03 06:09:29 EDT; 1min 19s ago
 Main PID: 30075 (sssd)
    Tasks: 6 (limit: 39320)
   Memory: 40.4M
   CGroup: /system.slice/sssd.service
           ├─30075 /usr/sbin/sssd -i --logger=files
           ├─30076 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
           ├─30077 /usr/libexec/sssd/sssd_be --domain example1 --uid 0 --gid 0 --logger=files
           ├─30079 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           ├─30080 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
           └─30081 /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --logger=files

Sep 03 06:09:28 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[30075]: (Tue Sep  3 06:09:28 2019) [sssd[be[example1]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x564942e2e650
Sep 03 06:09:28 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[30075]: (Tue Sep  3 06:09:28 2019) [sssd[be[example1]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x564942e2e720
Sep 03 06:09:28 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[30075]: (Tue Sep  3 06:09:28 2019) [sssd[be[example1]]] [ldb] (0x4000): Running timer event 0x564942e2e650 "ltdb_callback"
Sep 03 06:09:28 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[30075]: (Tue Sep  3 06:09:28 2019) [sssd[be[example1]]] [ldb] (0x4000): Destroying timer event 0x564942e2e720 "ltdb_timeout"
Sep 03 06:09:28 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[30075]: (Tue Sep  3 06:09:28 2019) [sssd[be[example1]]] [ldb] (0x4000): Destroying timer event 0x564942e2e650 "ltdb_callback"
Sep 03 06:09:28 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[be[example1]][30077]: Starting up
Sep 03 06:09:29 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[nss][30079]: Starting up
Sep 03 06:09:29 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[pam][30080]: Starting up
Sep 03 06:09:29 dell-r730-015.dsal.lab.eng.rdu2.redhat.com sssd[ifp][30081]: Starting up
Sep 03 06:09:29 dell-r730-015.dsal.lab.eng.rdu2.redhat.com systemd[1]: Started System Security Services Daemon.

No crashes seen. Marking it verified.

Comment 13 errata-xmlrpc 2019-11-05 22:34:01 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/RHSA-2019:3651

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