Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=883106 (Red Hat Enterprise Linux 6)
Description of problem: sudo access denial response is sometimes incorrect, when a rule sudoHost attribute mismatches. This happens after the relevant rule was changed from matching sudoHost to mismatching sudoHost a few times with a smart refresh in between match and nonmatch changes. After several more iterations the response seems to stabilize on being incorrect and responses are given noticeably faster. Version-Release number of selected component (if applicable): sssd-1.9.2-30.el6.x86_64 libsss_sudo-1.9.2-30.el6.x86_64 sudo-1.8.6p3-6.el6.x86_64 sssd-client-1.9.2-30.el6.x86_64 libsss_idmap-1.9.2-30.el6.x86_64 How reproducible: always Steps to Reproduce: 1. Use the attached "sudo_host_refresh_test.ldif" file to fill LDAP directory. 2. Use the attached "sssd.conf" file as the base for SSSD configuration. 3. Execute the attached "sudo_host_refresh_test" script with "sssd" argument. Actual results: ---:<--- user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561769 1/1: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561771 1/2: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561772 1/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561774 1/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561775 1/5: 1 user1 is not in the sudoers file. This incident will be reported. 1354561782 2/1: 1 sudo: no tty present and no askpass program specified 1354561783 2/2: 1 sudo: no tty present and no askpass program specified 1354561785 2/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561785 2/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354561786 2/5: 1 user1 is not in the sudoers file. This incident will be reported. 1354561793 3/1: 1 sudo: no tty present and no askpass program specified 1354561795 3/2: 1 sudo: no tty present and no askpass program specified 1354561796 3/3: 1 sudo: no tty present and no askpass program specified 1354561796 3/4: 1 sudo: no tty present and no askpass program specified 1354561797 3/5: 1 user1 is not in the sudoers file. This incident will be reported. 1354561804 4/1: 0 sudo: no tty present and no askpass program specified 1354561805 4/2: 1 sudo: no tty present and no askpass program specified 1354561805 4/3: 1 sudo: no tty present and no askpass program specified 1354561805 4/4: 1 sudo: no tty present and no askpass program specified 1354561805 4/5: 1 sudo: no tty present and no askpass program specified 1354561811 5/1: 1 sudo: no tty present and no askpass program specified 1354561811 5/2: 1 sudo: no tty present and no askpass program specified 1354561811 5/3: 1 sudo: no tty present and no askpass program specified 1354561811 5/4: 1 sudo: no tty present and no askpass program specified 1354561812 5/5: 1 --->:--- The lines after sudo responses contain timestamp in seconds, match/non-match change iteration number, sudo execution attempt number and sudo exit status. The "user1 is not allowed to run sudo on client-rhel6. This incident will be reported." response is correct. The "user1 is not in the sudoers file. This incident will be reported." response is unusual and is likely incorrect, but the text itself is suitable more-or-less. The "sudo: no tty present and no askpass program specified" response is definitely incorrect as it goes against the "defaults" entry. Please note the definitely incorrect exit status of 0 in the 4/1 entry. Also note how much faster the responses are given after that entry. This could signify some internal state corruption. Expected results: ---:<--- user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562694 1/1: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562695 1/2: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562695 1/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562695 1/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562695 1/5: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562695 2/1: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562695 2/2: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 2/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 2/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 2/5: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 3/1: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 3/2: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 3/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 3/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 3/5: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 4/1: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 4/2: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 4/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 4/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 4/5: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 5/1: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 5/2: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 5/3: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 5/4: 1 user1 is not allowed to run sudo on client-rhel6. This incident will be reported. 1354562696 5/5: 1 --->:--- The output above is produced with "sudoers" set to "ldap" in /etc/nsswitch.conf and the attached "sudo_host_refresh_test" script invoked with "ldap" argument.
Meaning of the messages:
user1 is not allowed to run sudo on client-rhel6. This incident will be reported. = 0 or more rules were returned by sssd, but host didn't match user1 is not in the sudoers file. This incident will be reported. = error was returned by sssd or user does not exist in sssd Sorry, user user1 is not allowed to execute '/bin/true' as user2 on client-rhel6.sss-test.test. = 0 or rules were returned by sssd, host matched, command or runasuser didn't match no tty present and no askpass program specified = everything is valid, but no tty is present
_comment0: Meaning of the messages:
{{{ user1 is not allowed to run sudo on client-rhel6. This incident will be reported. = rules were returned by sssd, but host didn't match
user1 is not in the sudoers file. This incident will be reported. = no rules were returned by sssd
Sorry, user user1 is not allowed to execute '/bin/true' as user2 on client-rhel6.sss-test.test. = rules were returned by sssd, host matched, command or runasuser didn't match
no tty present and no askpass program specified = everything is valid, but no tty is present }}} => 1355402294357681 blockedby: => blocking: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => testsupdated: => 0
Smart refresh doesn't detect modification of sudoHost from valid hostname to invalid. Such changes requires the rule to be deleted from sysdb, but smart refresh is not supposed to delete anything. So this is by design.
Such changes are supposed to be detected by refreshing expired rules.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.10 beta
owner: somebody => pbrezina status: new => assigned
I managed to reproduce this issue on RHEL6.4 machine. I modified Nikolai's test to take a dump of sysdb after each sudo command. The cache is always consistent with the LDAP, so the problem is probably on sudo side. I will investigate more.
From further view, it looks like sudo has sometimes trouble communicating with sssd.
handle->fn_send_recv_defaults: != 0, sss_error=32540 ... handle->fn_send_recv: != 0: ret=111 (Connection refused) Results in: sudo: no tty present and no askpass program specified
sss_error is different every time. Defaults rule went ok once and it hit only ret=111.
I didn't find any significant difference between logs with correct output and "user-1 is not in the sudoers file. This incident will be reported.".
selected: => Not need
Moving tickets that are not a priority for SSSD 1.10 into the next release.
milestone: SSSD 1.10 beta => SSSD 1.11 beta
I would like to have this bug fixed earlier as it interferes with automated testing considerably.
Currently 20 of about 100 tests in sudo suite are waived because of it.
milestone: SSSD 1.11 beta => NEEDS_TRIAGE
milestone: NEEDS_TRIAGE => SSSD 1.10.0
milestone: SSSD 1.10.0 => SSSD 1.10.1
changelog: => patch: 0 => 1 review: => 0
resolution: => fixed status: assigned => closed
milestone: SSSD 1.10.1 => SSSD 1.10.0
changelog: => N/A, just a bugfix
Metadata Update from @jhrozek: - Issue assigned to pbrezina - Issue set to the milestone: SSSD 1.10.0
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/2735
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.