Description of problem: Sudo not working for IPA sudo_provider. Version-Release number of selected component (if applicable): [root@auto-hv-02-guest05 ~]# rpm -q ipa-server sssd ipa-server-3.0.0-50.el6.x86_64 sssd-1.13.3-15.el6.x86_64 [root@auto-hv-02-guest05 ~]# How reproducible: Always Steps to Reproduce: On IPA Master: (1) Added sudorule for IPA client machine for user "testuser1" for command "mkdir" [root@auto-hv-02-guest05 ~]# ipa sudorule-show sudorule2 Rule name: sudorule2 Enabled: TRUE Users: testuser1 Hosts: ipaqa64vml.testrelm.test Sudo Allow Commands: /bin/mkdir [root@auto-hv-02-guest05 ~]# echo xxxxxxxx|kinit testuser1 Password for testuser1: On IPA Client: (2)Add sudo_provider with ipa in sssd.conf On IPA Master: (3)Do ssh with user testuser1 to IPA client machine . Now Try 'sudo -l' on IPA client machine Saw following on console. "User testuser1 is not allowed to run sudo on ipaqa64vml." But instead it it should have shown that user can run 'mkdir' command on this host. [root@auto-hv-02-guest05 ~]# [root@auto-hv-02-guest05 ~]# ssh -o StrictHostKeyChecking=no -l testuser1 ipaqa64vml.testrelm.test Last login: Wed Mar 2 07:33:28 2016 from auto-hv-02-guest05.testrelm.test ... .... Could not chdir to home directory /home/testuser1: No such file or directory -sh-4.1$ sudo -l [sudo] password for testuser1: User testuser1 is not allowed to run sudo on ipaqa64vml. -sh-4.1$ logout Connection to ipaqa64vml.testrelm.test closed. [root@auto-hv-02-guest05 ~]# On IPA Client: (4) following shown in sssd_sudo.log (Wed Mar 2 10:06:33 2016) [sssd[sudo]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Wed Mar 2 10:06:34 2016) [sssd[sudo]] [sbus_remove_timeout] (0x2000): 0x10b0a70 (Wed Mar 2 10:06:34 2016) [sssd[sudo]] [sbus_dispatch] (0x4000): dbus conn: 0x10ae830 (Wed Mar 2 10:06:34 2016) [sssd[sudo]] [sbus_dispatch] (0x4000): Dispatching. (Wed Mar 2 10:06:34 2016) [sssd[sudo]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 5 error message: Internal Error (Wed Mar 2 10:06:34 2016) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x10b31b0 (Wed Mar 2 10:06:34 2016) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x10b32d0 Actual results: sudo command to be executed not shown with 'sudo -l' Expected results: sudo command to be executed should be shown with 'sudo -l' Additional info: (1)When sudo_provider changed to ldap provider, 'sudo -l' gives correct output. Thanks to Jakub for this.
Assigning to author sudo related changes in sssd-1.13
Upstream ticket: https://fedorahosted.org/sssd/ticket/2969
Sounds good. Ack.
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