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

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

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.4

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

resolution: => fixed
status: assigned => closed

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

2 years ago

Login to comment on this ticket.

Metadata