SSSD / sssd

#1736 Smart refresh doesn't notice "defaults" addition with OpenLDAP
Closed: Fixed Opened by jhrozek.

Closed: Fixed
Reopen Issue

https://bugzilla.redhat.com/show_bug.cgi?id=891356 (Red Hat Enterprise Linux 6)

Description of problem:
Smart refresh doesn't notice a newly added "defaults" entry with OpenLDAP
server. It gets noticed only after full refresh.
Version-Release number of selected component (if applicable):
libsss_idmap-1.9.2-59.el6.x86_64
sssd-client-1.9.2-59.el6.x86_64
sudo-1.8.6p3-6.el6.x86_64
sssd-1.9.2-59.el6.x86_64
libsss_sudo-1.9.2-59.el6.x86_64
openldap-servers-2.4.23-31.el6.x86_64
How reproducible:
always
Steps to Reproduce:
1. Use the attached sudo_defaults_openldap_test.ldif file to fill LDAP
directory.
2. Use the attached sssd.conf as the base for SSSD configuration.
3. Execute the attached sudo_defaults_openldap_test script as root after
modifying it to connect to the LDAP server.
Actual results:
sudo: no tty present and no askpass program specified
initially: 1
sudo: no tty present and no askpass program specified
smart_refresh_with_rule_added: 1
sudo: no tty present and no askpass program specified
smart_refresh_with_defaults_added: 1
full_refresh_with_defaults_added: 0
Expected results:
sudo: no tty present and no askpass program specified
initially: 1
sudo: no tty present and no askpass program specified
smart_refresh_with_rule_added: 1
smart_refresh_with_defaults_added: 0
full_refresh_with_defaults_added: 0
Additional info:
This works with sssd sudo backend and 389-ds and with LDAP sudo backend and
OpenLDAP server.

Fields changed

blockedby: =>
blocking: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
owner: somebody => pbrezina
selected: =>
status: new => assigned
testsupdated: => 0

Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=891635 (Red Hat Enterprise Linux 6)

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356] => [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356], [https://bugzilla.redhat.com/show_bug.cgi?id=891635 891635]

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.4

https://bugzilla.redhat.com/show_bug.cgi?id=891635 was actually not a bug and it wasn't related to 891356 after all.

rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356], [https://bugzilla.redhat.com/show_bug.cgi?id=891635 891635] => [https://bugzilla.redhat.com/show_bug.cgi?id=891356 891356]

I managed to reproduce this issue.
The problem is that OpenLDAP check whether the filter contains schema-correct value for modifyTimestamp attribute.

So instead of modifyTimestamp>=0, we should use modifyTimestamp>=000101010000Z in smart refresh.

_comment0: I managed to reproduce this issue.
The problem is that OpenLDAP check whether the filter contains schema-correct value for modify timestamp.

So instead of modifyTimestamp>=0, we should use modifyTimestamp>=000101010000Z. => 1357306071915858

Or we can just avoid using modifyTimestamp in filter at all when it is 0.

Fields changed

patch: 0 => 1
  • master:
    • 7ed683eba94b5bcdc4fe3f9037d80d0fedcddfd0
    • 023ebc3d7e76978cfe7952480e0d7d88a2e1f690
  • sssd-1-9:
    • 1d8a60c1cc583c20b09eccb16051bdd68d311f77
    • d1a77741940f720bf11ff1718843f04d1410ccec

resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to pbrezina
- Issue set to the milestone: SSSD 1.9.4

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/2778

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None
None
None
Normal
defect
SSSD
None
0
1
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.