Bug 1313940

Assigning to author sudo related changes in sssd-1.13

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

Sounds good. Ack.

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

Patch is on review, devel acking.

    master:
        b0c4eb194cf1414d3440e0cccfb9af9074388c08
        84060f52e782b079337ee7a99bb7ad17e8c84fbb 
    sssd-1-13:
        6ece710965c30cc34fb32e87c0350fbac5f36dad
        1434e5609fb7f6b234811717ff2b6ff495272707

Tried with latest build sssd-1.13.3-19.el6.x86_64 but bug still there


[root@ibm-x3250m4-04 ~]# rpm -q ipa-client sssd
ipa-client-3.0.0-50.el6.x86_64
sssd-1.13.3-19.el6.x86_64
[root@ibm-x3250m4-04 ~]# 

snip from sssd.<domain>.log
===========================

(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sdap_get_generic_op_finished] (0x2000): Total count [0]
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sdap_op_destructor] (0x2000): Operation 11 finished
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sdap_search_bases_done] (0x0400): Receiving data from base [cn=sudo,dc=testrelm,dc=test]
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [process_rulemember] (0x0080): Invalid member DN sudocmd=/bin/mkdir,cn=sudocmds,cn=sudo,dc=testrelm,dc=test, skipping...
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ipa_sudo_fetch_cmdgroups] (0x0400): About to fetch sudo command groups
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ipa_sudo_fetch_cmdgroups] (0x0400): No command groups needs to be downloaded
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ipa_sudo_fetch_cmds] (0x0400): About to fetch sudo commands
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ipa_sudo_fetch_cmds] (0x0400): No commands needs to be downloaded
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ipa_sudo_fetch_done] (0x0400): About to convert rules
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ldb] (0x4000): start ldb transaction (nesting: 0)
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [ldb] (0x4000): start ldb transaction (nesting: 1)
(Wed Mar 16 03:50:13 2016) [sssd[be[testrelm.test]]] [sysdb_sudo_purge_all] (0x0400): Deleting all cached sudo rules

I'm sorry about that, I built a new package where the patches are actually applied

Fixed in sssd-1.13.3-21.el6.

I have two observations with latest build sssd-1.13.3-22.el6.x86_64

(1)sudo run on client vm still fails in first attempt and after waiting 5 minutes second attempt is successful . Please find the attached file with console output for this.

(2)First sudo run attempt is also successful but when sssd cache removed on client vm before running sudo command on it.

is this a separate issue or part of this bug which needs to be fixed?

Created attachment 1139405 [details]
console output with steps

Ok, so I can confirm that the issue *is* fixed. If you add a sudo rule you need to wait some time till SSSD downloads it through either smart or full refresh (please refer to sssd-sudo man page).

Ad 1) The first attempt is not successful because the rule was not yet downloaded. During the five minutes delay a smart refresh occurred and downloaded newly added rule. Therefore second attempt is successful.

Ad 2) If you restart SSSD with a clear cache, full refresh that downloads all rules happens immediately (and with 10 seconds delay if the cache is not clear). Therefore the rules is there immediately.

If you are not testing specific sudo refresh type, it is good to remove cache and restart sssd so the changes take effect immediately. If you are testing refresh types you can decrease the period with ldap_sudo_*_refresh_interval.

Verified as per #c26

IPA/sssd version:
=================
ipa-client-3.0.0-50.el6.x86_64
ipa-server-3.0.0-50.el6.x86_64
sssd-ipa-1.13.3-22.el6.x86_64


snip from automation log:
=========================
:: [  BEGIN   ] :: Running 'ipa sudorule-add-allow-command --sudocmds=/bin/mkdir sudorule1'
  Rule name: sudorule1
  Enabled: TRUE
  Users: user1
  Hosts: ibm-x3250m4-02.testrelm.test
  Sudo Allow Commands: /bin/mkdir
-------------------------
Number of members added 1
-------------------------
:: [   PASS   ] :: Command 'ipa sudorule-add-allow-command --sudocmds=/bin/mkdir sudorule1' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'sssd_cache_cleanup'
Stopping sssd: [  OK  ]
Starting sssd: [  OK  ]
:: [   PASS   ] :: Command 'sssd_cache_cleanup' (Expected 0, got 0)
:: [  BEGIN   ] :: Running 'sudo_list user1'
#!/usr/bin/expect -f

set timeout 30
set send_slow {1 .1}
match_max 100000

spawn ssh -o StrictHostKeyChecking=no -l user1 ibm-x3250m4-02.testrelm.test
expect "*: "
send -s "xxxxxxxx\r"
expect "*$ "
send -s "sudo -l > /tmp/sudo_list_client_25647.out 2>&1 \r"
expect "user1: "
send -s "xxxxxxxx\r"
expect eof
spawn ssh -o StrictHostKeyChecking=no -l user1 ibm-x3250m4-02.testrelm.test
user1.test's password: 
Last login: Tue Mar 29 01:38:14 2016 from ibm-x3250m4-02.testrelm.test

**  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **
.....
6.8-20160329.n.0                             
**  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **
Could not chdir to home directory /home/user1: No such file or directory
-sh-4.1$ 
MARK-LWD-LOOP -- 2016-03-29 01:39:53 --
sudo -l > /tmp/sudo_list_client_25647.out 2>&1 
[sudo] password for user1: 
-sh-4.1$ ibm-x3250m4-02.testrelm.test
Connecting to ibm-x3250m4-02.testrelm.test...
Fetching /tmp/sudo_list_client_25647.out to /tmp/sudo_list.out
Matching Defaults entries for user1 on this host:
    !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME
    HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME
    LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION
    LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC
    LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS
    _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User user1 may run the following commands on this host:
    (root) /bin/mkdir
:: [   PASS   ] :: Command 'sudo_list user1' (Expected 0, got 0)
:: [   PASS   ] :: File '/tmp/sudo_list.out' should contain 'User user1 may run the following commands on this host:' 
:: [   PASS   ] :: File '/tmp/sudo_list.out' should contain '(root) /bin/mkdir'

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.

https://rhn.redhat.com/errata/RHBA-2016-0782.html