Created attachment 646348 [details]
Base LDIF file

Created attachment 646349 [details]
sssd.conf

Hi,
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

Pavel,

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:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahy%2Frzahyutctime.htm

Oh, I didn't notice the additional info. OK then. This needs to be fixed on sssd side.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1712

Fixed upstream.

The testing has shown that the current implementation doesn't support specifying only the sudoNotBefore or sudoNotAfter attribute as the sudoers LDAP backend does.

OK. I can confirm that sudo-ldap can deal with only one time attribute present. I will prepare a patch.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2100

The notBefore/notAfter enhancements were commited upstream:
    master: d1f3610aefcb634f212d4c099fac102b3e4dee59
    sssd-1-11: 9f3e9e9984e48bb45c6c3fb8f49b0ff5bf337393

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
GRANTED, sudoNotAfter, DENIED
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.

Hi,
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?

Thanks.

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.

Created attachment 848256 [details]
sudo_notbefore_notafter_test

Created attachment 848257 [details]
sudo_notbefore_notafter_test.ldif

Created attachment 848258 [details]
sudo_notbefore_notafter_test_sssd.conf

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.

Sorry, it's "notbefore_before" that fails intermittently with "sssd" sudo backend, not "notbefore_after". The latter never fails.

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

The LDAP sudo backend tests fail for me with 389-ds, but not with OpenLDAP server.

The sssd sudo backend tests fail for me with either LDAP server.

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?

The environment is prepared. Pavel, please request details on IRC.

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.

notbefore_before:
<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

notbefore_after:
<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.

I found the root cause of this issue. The problem is that strptime() does not initialize tm_isdst field.

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2213

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)

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.