Learn more about these different git repos.
Other Git URLs
A user on the #sssd channel hit a segfault when processing an ASQ dereference request. This may or may not be the same issue as #1894, so they should be investigated together.
The backtrace was:
Program received signal SIGSEGV, Segmentation fault. sdap_asq_search_parse_entry (sh=0x85feb0, msg=0xdd74e0, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:1967 1967 for (i = 0; vals[i]; i++) { Missing separate debuginfos, use: debuginfo-install nss-softokn-3.12.9-11.el6.x86_64 sqlite-3.6.20-1.el6.x86_64 (gdb) bt #0 sdap_asq_search_parse_entry (sh=0x85feb0, msg=0xdd74e0, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:1967 #1 0x00007fc8a4328d91 in sdap_get_generic_ext_done (op=<value optimized out>, reply=0xdd74e0, error=0, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:1347 #2 0x00007fc8a432eb1f in sdap_process_message (ev=<value optimized out>, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:366 #3 sdap_process_result (ev=<value optimized out>, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:209 #4 0x00000034caa07bd9 in tevent_common_loop_timer_delay () from /usr/lib64/libtevent.so.0 #5 0x00000034caa072ab in ?? () from /usr/lib64/libtevent.so.0 #6 0x00000034caa038f0 in _tevent_loop_once () from /usr/lib64/libtevent.so.0 #7 0x00000034caa0395b in tevent_common_loop_wait () from /usr/lib64/libtevent.so.0 #8 0x00007fc8ac8a38d3 in server_loop (main_ctx=0x82b6d0) at src/util/server.c:602 #9 0x0000000000413626 in main (argc=<value optimized out>, argv=<value optimized out>) at src/providers/data_provider_be.c:2771
Debug log from the above backtrace (sanitized with [...]). Interesting part is probably around line 53200. debug-sanitized.gz
Fields changed
owner: somebody => lslebodn patch: 0 => 1
milestone: NEEDS_TRIAGE => SSSD 1.10 beta rhbz: => todo
resolution: => fixed status: new => closed
The fix only adds a NULL check, doesn't solve the issue of why was the objectclass missing. But hopefully the new debug message added with the commit would tell us which entry was misbehaving and we'll be able to inspect it in LDAP.
No RHEL clone is needed, this was not reported by a RHEL customer and we never saw the problem again.
rhbz: todo => 0
Hello guys,
I faced the "objectclass missing" message. Isn't this one?
'Unknown entry type, no objectClass found for DN'
So, the problem happens when loading the groups for a user. For example:
LDAP server is AD 2k8
LDAP is connected with anonymous user (I guess this will happen even if authenticated)
user1 is member of group1, group2, group3
user2 is member of group2
When user1 logs in, sssd loads all its groups. When a group is loaded, all its members are also checked (looking for nested groups?). In this case, when loading group2, sssd looks for user2. If the current ldap conn user (anonymous in this case) does not have permission to read user2 attributes, no objectclass is returned. SSSD fails with the cited message and group expansion stops. For SSSD, user1 only belongs to group1 as group2 failed and group3 didn't even had the chance to be loaded. The nice behavior would be to skip user2 and go on.
It is very easy to reproduce. Just add a user to a group in a AD and remove in Security tab all permission to the used "ldap conn user".
I'm currently using OpenSuSE Leap package (1.11.5.1). Is there a patch on master that fixes this issue?
_comment0: Hello guys,
LDAP server is AD 2k8 LDAP is connected with anonymous user (I guess this will happen even if authenticated)
user1 is member of group1, group2, group3 user2 is member of group2
I'm currently using OpenSuSE Leap package (1.11.5.1). Is there a patch on master that fixes this issue? => 1448659259096418 changelog: => mark: => 0 sensitive: => 0
Replying to [comment:6 luizluca]:
It is very easy to reproduce. Just add a user to a group in a AD and remove in Security tab all permission to the used "ldap conn user". I'm currently using OpenSuSE Leap package (1.11.5.1). Is there a patch on master that fixes this issue?
The patch is in the comment:3 but it it is already in sssd >= 1.10.0.
BTW I asked openSUSE maintainer to upgrade to latest sssd-1.11 or sssd-1.12 because 1.11.5.1 is buggy. Unfortunately, the request was revoked https://build.opensuse.org/request/show/337995
I would recommend you to test with newer version (1.12.5 or 1.13.2). You might use repositories from openSUSE Build Service https://build.opensuse.org/package/show/network:ldap/sssd
zypper addrepo -f http://download.opensuse.org/repositories/network:/ldap/openSUSE_Leap_42.1/network:ldap.repo
Metadata Update from @jhrozek: - Issue assigned to lslebodn - Issue set to the milestone: SSSD 1.10 beta
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2992
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.