Bug 877438 - sudoNotBefore/sudoNotAfter not supported by sssd sudoers plugin
Summary: sudoNotBefore/sudoNotAfter not supported by sssd sudoers plugin
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
Depends On:
TreeView+ depends on / blocked
Reported: 2012-11-16 14:46 UTC by Nikolai Kondrashov
Modified: 2014-06-18 03:59 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2014-06-13 10:12:31 UTC

Attachments (Terms of Use)
Base LDIF file (3.17 KB, text/x-ldif)
2012-11-16 14:47 UTC, Nikolai Kondrashov
no flags Details
sssd.conf (659 bytes, text/plain)
2012-11-16 14:47 UTC, Nikolai Kondrashov
no flags Details
sudo_notbefore_notafter_test (5.25 KB, text/plain)
2014-01-10 15:32 UTC, Nikolai Kondrashov
no flags Details
sudo_notbefore_notafter_test.ldif (1.05 KB, text/plain)
2014-01-10 15:32 UTC, Nikolai Kondrashov
no flags Details
sudo_notbefore_notafter_test_sssd.conf (525 bytes, text/plain)
2014-01-10 15:33 UTC, Nikolai Kondrashov
no flags Details

Description Nikolai Kondrashov 2012-11-16 14:46:51 UTC
Description of problem:
The sssd sudoers plugin doesn't support sudoNotBefore and sudoNotAfter attributes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Use the attached LDIF file to fill LDAP directory
2. Use the attached sssd.conf as the base for client configuration
3. Execute "su -c 'sudo -u user2 whoami' user1" as root
Actual results:
sudo: no tty present and no askpass program specified

(NOTE: the actual result above is also affected by Bug 875740)

Expected results:

Additional info:
The LDAP sudoers plugin works as documented.

Comment 1 Nikolai Kondrashov 2012-11-16 14:47:16 UTC
Created attachment 646348 [details]
Base LDIF file

Comment 2 Nikolai Kondrashov 2012-11-16 14:47:53 UTC
Created attachment 646349 [details]

Comment 4 Pavel Březina 2012-12-11 11:50:40 UTC
quoting sudoers.ldap man page:
"A timestamp in the form yyyymmddHHMMSSZ"
"Note that timestamps must be in Coordinated Universal Time (UTC), not the local timezone."

You just used invalid timestamp format. You must always use UTC+0 which is represented by 'Z' character at the end e.g. 20121116162421Z

Comment 5 Nikolai Kondrashov 2012-12-11 16:07:59 UTC

First of all, as noted in the bug description, this works with LDAP backend.

Next, the sudoers.ldap man page is confusing. The format is not even
interpreted by sudo, but the LDAP server instead. Look at sudo_ldap_timefilter
in plugins/sudoers/ldap.c.

They should've probably referred to RFC 4517, section "3.3.13. Generalized
Time" and maybe also section "3.3.34. UTC Time".

See this article for a summary:

Comment 6 Pavel Březina 2012-12-12 13:30:22 UTC
Oh, I didn't notice the additional info. OK then. This needs to be fixed on sssd side.

Comment 7 Pavel Březina 2012-12-12 13:32:09 UTC
Upstream ticket:

Comment 8 Jakub Hrozek 2013-03-26 18:15:43 UTC
Fixed upstream.

Comment 9 Nikolai Kondrashov 2013-09-25 09:09:42 UTC
The testing has shown that the current implementation doesn't support specifying only the sudoNotBefore or sudoNotAfter attribute as the sudoers LDAP backend does.

Comment 10 Pavel Březina 2013-09-25 13:19:26 UTC
OK. I can confirm that sudo-ldap can deal with only one time attribute present. I will prepare a patch.

Comment 11 Jakub Hrozek 2013-09-26 09:42:49 UTC
Upstream ticket:

Comment 12 Jakub Hrozek 2013-10-01 19:29:25 UTC
The notBefore/notAfter enhancements were commited upstream:
    master: d1f3610aefcb634f212d4c099fac102b3e4dee59
    sssd-1-11: 9f3e9e9984e48bb45c6c3fb8f49b0ff5bf337393

Comment 14 Nikolai Kondrashov 2013-12-09 09:55:14 UTC
Verified as *NOT* fixed with sssd 1.11.2-10.el7.x86_64.

With sudoNotBefore alone, access is granted before clock passes its value, unexpectedly, most of the time, but sometimes it is denied as expected. Access is granted afterwards, as expected.

With sudoNotAfter alone, access is never granted before clock passes its value, unexpectedly. It is denied afterwards, as expected.

With sudoNotBefore and sudoNotAfter together, with the latter greater than the former, access is never granted with clock between the values, unexpectedly. It is denied outside the range, as expected.

Observed behavior summary:

*GRANTED*, sudoNotBefore, GRANTED
*DENIED*, sudoNotAfter, DENIED
DENIED, sudoNotBefore, *DENIED*, sudoNotAfter, DENIED
DENIED, sudoNotAfter, DENIED, sudoNotBefore, DENIED

Expected behavior summary:

DENIED, sudoNotBefore, GRANTED
DENIED, sudoNotBefore, GRANTED, sudoNotAfter, DENIED
DENIED, sudoNotAfter, DENIED, sudoNotBefore, DENIED

NOTE: The same tests work with the sudo's pure LDAP backend and follow the above expected behavior.

Comment 18 Pavel Březina 2013-12-19 11:58:44 UTC
I'm sorry but I can't reproduce it on my own. In my tests those attributes works as expected. Could you please send me a reproducer?


Comment 19 Jakub Hrozek 2014-01-08 03:14:17 UTC
Nikolai, did you have a chance to work with Pavel on setting up the reproducer? Please CC me if you send an e-mail, Pavel might not be available these days.

Comment 20 Nikolai Kondrashov 2014-01-10 15:32:27 UTC
Created attachment 848256 [details]

Comment 21 Nikolai Kondrashov 2014-01-10 15:32:56 UTC
Created attachment 848257 [details]

Comment 22 Nikolai Kondrashov 2014-01-10 15:33:25 UTC
Created attachment 848258 [details]

Comment 23 Nikolai Kondrashov 2014-01-10 15:40:19 UTC
Sorry for the delay. Please find test script and data attached.

Use sudo_notbefore_notafter_test.ldif as the base directory contents.
Use sudo_notbefore_notafter_test_sssd.conf as the base for sssd.conf.
Modify sudo_notbefore_notafter_test to match local setup and then execute as root with either "sssd" or "ldap" argument for sudo "sssd" or "ldap" backend setup correspondingly.

The script output specifies all tests as passed with the "ldap" sudo backend. With the "sssd" sudo backend "notbefore_after" fails most of the time, "notafter_before" and "notbefore_notafter_within" fail always.

All tests are supposed to pass for "sssd" sudo backend as well.

Comment 24 Nikolai Kondrashov 2014-01-10 15:55:54 UTC
Sorry, it's "notbefore_before" that fails intermittently with "sssd" sudo backend, not "notbefore_after". The latter never fails.

Comment 25 Pavel Březina 2014-01-21 10:50:17 UTC
Hi Nikolai,
I'm getting different results. SSSD tests are all green, but ldap is failing for me. (always the same tests)

# cat /etc/nsswitch.conf | grep sudoers
sudoers: sss
# ./sudo_notbefore_notafter_test sssd
notbefore_before                 DENIED  PASSED
notbefore_after                  ALLOWED PASSED
notafter_before                  ALLOWED PASSED
notafter_after                   DENIED  PASSED
notbefore_notafter_before        DENIED  PASSED
notbefore_notafter_within        ALLOWED PASSED
notbefore_notafter_after         DENIED  PASSED
notafter_notbefore_before        DENIED  PASSED
notafter_notbefore_within        DENIED  PASSED
notafter_notbefore_after         DENIED  PASSED

# cat /etc/nsswitch.conf | grep sudoers
sudoers: ldap
# ./sudo_notbefore_notafter_test ldap
notbefore_before                 DENIED  PASSED
notbefore_after                  DENIED  FAILED
notafter_before                  ALLOWED PASSED
notafter_after                   ALLOWED FAILED
notbefore_notafter_before        DENIED  PASSED
notbefore_notafter_within        DENIED  FAILED
notbefore_notafter_after         DENIED  PASSED
notafter_notbefore_before        DENIED  PASSED
notafter_notbefore_within        DENIED  PASSED
notafter_notbefore_after         DENIED  PASSED

Comment 26 Nikolai Kondrashov 2014-01-21 11:31:56 UTC
The LDAP sudo backend tests fail for me with 389-ds, but not with OpenLDAP server.

Comment 27 Nikolai Kondrashov 2014-01-21 11:33:10 UTC
The sssd sudo backend tests fail for me with either LDAP server.

Comment 28 Jakub Hrozek 2014-01-21 23:04:47 UTC
Nikolai, given that Pavel had had time reproducing the bug and you can reproduce it on will, would you mind prepairing a test setup where Pavel could take a look?

Comment 29 Nikolai Kondrashov 2014-01-22 09:17:24 UTC
The environment is prepared. Pavel, please request details on IRC.

Comment 30 Pavel Březina 2014-01-23 10:24:42 UTC
I put some more debug information around the functions that performs time filtering. It prints selected time format together with string value of ldap attribute (sudoNotBefore in this case), current time and attribute value converted to unix timestamp. This is the output for failed notbefore_before and notbefore_after tests - i.e. SSSD was not restarted, the rule did not change between these test.

<pbrezina> (Thu Jan 23 11:10:24 2014) [sssd[sudo]] [sysdb_sudo_convert_time] (0x0010): format: %Y%m%d%H%M%S%z string: 20140123111033+0100
<pbrezina> (Thu Jan 23 11:10:24 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): now:       1390471824
<pbrezina> (Thu Jan 23 11:10:24 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): notbefore: 1390468233
<pbrezina> (Thu Jan 23 11:10:24 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): notafter:  0
<pbrezina> (Thu Jan 23 11:10:24 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): result:    true

<pbrezina> (Thu Jan 23 11:10:37 2014) [sssd[sudo]] [sysdb_sudo_convert_time] (0x0010): format: %Y%m%d%H%M%S%z string: 20140123111033+0100
<pbrezina> (Thu Jan 23 11:10:37 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): now:       1390471837
<pbrezina> (Thu Jan 23 11:10:37 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): notbefore: 1390471833
<pbrezina> (Thu Jan 23 11:10:37 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): notafter:  0
<pbrezina> (Thu Jan 23 11:10:37 2014) [sssd[sudo]] [sysdb_sudo_check_time] (0x0010): result:    true

We have the same value of sudoNotBefore attribute, but the timestamp differers by one hour. It looks like there is some non-deterministic behaviour in either strptime() or mktime(), since those are the only functions that converts the attribute value. I will investigate more.

Comment 31 Pavel Březina 2014-01-29 11:54:21 UTC
I found the root cause of this issue. The problem is that strptime() does not initialize tm_isdst field.

Upstream ticket:

Comment 33 Nikolai Kondrashov 2014-02-07 22:55:43 UTC
Verified FIXED in sssd-1.11.2-37.el7.x86_64 with the SSSD sudo suite both with OpenLDAP and 389 directory servers:

:: [   PASS   ] :: attrs_notbefore_before (Expected 0, got 0)
:: [   PASS   ] :: attrs_notbefore_after (Expected 0, got 0)
:: [   PASS   ] :: attrs_notafter_before (Expected 0, got 0)
:: [   PASS   ] :: attrs_notafter_after (Expected 0, got 0)
:: [   PASS   ] :: attrs_notbefore_notafter_before (Expected 0, got 0)
:: [   PASS   ] :: attrs_notbefore_notafter_within (Expected 0, got 0)
:: [   PASS   ] :: attrs_notbefore_notafter_after (Expected 0, got 0)
:: [   PASS   ] :: attrs_notafter_notbefore_before (Expected 0, got 0)
:: [   PASS   ] :: attrs_notafter_notbefore_within (Expected 0, got 0)
:: [   PASS   ] :: attrs_notafter_notbefore_after (Expected 0, got 0)

Comment 34 Ludek Smid 2014-06-13 10:12:31 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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