#1693 sudoHost mismatch response is incorrect sometimes
Closed: Fixed None Opened 6 years ago by jhrozek.

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

Fields changed

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.".

Fields changed

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

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10.0

Fields changed

milestone: SSSD 1.10.0 => SSSD 1.10.1

Fields changed

changelog: =>
patch: 0 => 1
review: => 0

resolution: => fixed
status: assigned => closed

Fields changed

milestone: SSSD 1.10.1 => SSSD 1.10.0

Fields changed

changelog: => N/A, just a bugfix

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

2 years ago

Login to comment on this ticket.

Metadata