Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 869013 - Sudo smart refresh doesn't occur on time
Sudo smart refresh doesn't occur on time
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.4
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Jakub Hrozek
Kaushik Banerjee
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-22 14:34 EDT by Nikolai Kondrashov
Modified: 2013-02-21 04:37 EST (History)
4 users (show)

See Also:
Fixed In Version: sssd-1.9.2-5.el6
Doc Type: Bug Fix
Doc Text:
Cause: SUDO smart refresh was not performed if LDAP server did not contained any rule when SSSD started. Consequence: Newly created rules where found after a longer period of time than the ldap_sudo_smart_refresh_interval option says. Fix: SUDO smart refresh is performed. Result: Newly created rule are found within ldap_sudo_smart_refresh_interval time span.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 04:37:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Base ldif, sssd.conf and logs from the reproduction script (18.00 KB, application/x-gzip)
2012-10-22 14:34 EDT, Nikolai Kondrashov
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0508 normal SHIPPED_LIVE Low: sssd security, bug fix and enhancement update 2013-02-20 16:30:10 EST

  None (edit)
Description Nikolai Kondrashov 2012-10-22 14:34:55 EDT
Created attachment 631670 [details]
Base ldif, sssd.conf and logs from the reproduction script

Description of problem:
A sudo rule node newly added to the LDAP server doesn't get noticed by sssd within smart refresh interval, only within full refresh interval.

Version-Release number of selected component (if applicable):
libsss_autofs-1.9.2-3.el6.x86_64
libsss_idmap-1.9.2-3.el6.x86_64
libsss_sudo-1.9.2-3.el6.x86_64
sssd-client-1.9.2-3.el6.x86_64
sssd-1.9.2-3.el6.x86_64

How reproducible:
Always.

Steps to Reproduce:
#
# Setup
#
service sssd stop
echo "ldap_sudo_smart_refresh_interval = 10" >> /etc/sssd/sssd.conf
echo "ldap_sudo_full_refresh_interval = 30" >> /etc/sssd/sssd.conf
rm /var/lib/sss/db/*.ldb
service sssd start
# Wait for the service to really come up,
# see https://fedorahosted.org/sssd/ticket/1357
# Without this delay the bug won't reproduce
sleep 3
check_sudo() { su user1 -c 'sudo -u user2 true' 2>/dev/null && echo ALLOWED || echo DENIED; }
#
# Test
#
check_sudo
ldapmodify -x -h server -D 'cn=Directory Manager' -w Secret123 -a <<EOF
dn: cn=test,ou=Sudoers,dc=example,dc=com
cn: test
objectClass: top
objectClass: sudoRole
sudoOption: !authenticate
sudoUser: ALL
sudoHost: ALL
sudoCommand: ALL
sudoRunAsUser: ALL
EOF
check_sudo; sleep 12; check_sudo; sleep 10; check_sudo; sleep 10; check_sudo
#
# Teardown
#
unset check_sudo
service sssd stop
grep -v 'ldap_sudo_\(smart\|full\)_refresh_interval' /etc/sssd/sssd.conf > /etc/sssd/sssd.conf.new
mv /etc/sssd/sssd.conf{.new,}
chmod 0600 /etc/sssd/sssd.conf
ldapdelete -x -h server -D 'cn=Directory Manager' -w Secret123 cn=test,ou=Sudoers,dc=example,dc=com
rm /var/lib/sss/db/*.ldb
service sssd start
  
Actual results:
DENIED
DENIED
DENIED
DENIED
ALLOWED

Expected results:
DENIED
DENIED
ALLOWED
ALLOWED
ALLOWED
Comment 2 Jakub Hrozek 2012-10-23 06:05:46 EDT
Pavel, can you check out the test and work with Nikolai on fixing this? Thanks!
Comment 3 Jakub Hrozek 2012-10-23 08:31:20 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1596
Comment 5 Jakub Hrozek 2012-10-24 12:26:20 EDT
Fixed upstream.
Comment 7 Nikolai Kondrashov 2012-12-14 11:56:19 EST
Verified fixed in following packages:

sssd-client-1.9.2-41.el6.x86_64
libsss_idmap-1.9.2-41.el6.x86_64
libsss_sudo-1.9.2-41.el6.x86_64
sudo-1.8.6p3-6.el6.x86_64
sssd-1.9.2-41.el6.x86_64

Relevant sudo suite output:

:: [   PASS   ] :: refresh_add_rule_before_smart
:: [   PASS   ] :: refresh_add_rule_after_smart
:: [   PASS   ] :: refresh_mod_rule_user_to_mismatch
:: [   PASS   ] :: refresh_mod_rule_user_to_match_before_smart
:: [   PASS   ] :: refresh_mod_rule_user_to_match_after_smart
:: [   PASS   ] :: refresh_mod_rule_command_to_mismatch
:: [   PASS   ] :: refresh_mod_rule_command_to_match
:: [   PASS   ] :: refresh_mod_rule_runasuser_to_mismatch
:: [   PASS   ] :: refresh_mod_rule_runasuser_to_match
:: [   PASS   ] :: refresh_mod_rule_runasgroup_to_mismatch
:: [   PASS   ] :: refresh_mod_rule_runasgroup_to_match
:: [   PASS   ] :: refresh_mod_rule_sudooption_to_require_auth
:: [   PASS   ] :: refresh_mod_rule_sudooption_to_not_require_auth
Comment 8 errata-xmlrpc 2013-02-21 04:37:51 EST
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.

http://rhn.redhat.com/errata/RHSA-2013-0508.html

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