Description of problem: I recently updated a laptop to Fedora 18. After this, I found that sudo no longer worked when used with sssd while away from my LDAP server. Version-Release number of selected component (if applicable): libsss_sudo-1.9.3-1.fc18.x86_64 How reproducible: Every time Steps to Reproduce: 1. Configure sudo to use LDAP/sssd 2. Connect to a LAN away from my LDAP server 3. Run "sudo ls" Actual results: "sudo ls" pauses for over one minute. Eventually it prompts me for a password. When I enter my password, sudo states, "mike is not in the sudoers file. This incident will be reported". Expected results: "sudo ls" should work, just like it does when the LDAP server is available. Additional info: I attached to sudo with gdb while it was "paused" as described above. Here the backtrace was: #0 0x00007f9ff4999970 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f9fea8e66fb in sss_cli_make_request_nochecks () from /usr/lib64/libsss_sudo.so #2 0x00007f9fea8e7c8f in sss_sudo_send_recv_generic () from /usr/lib64/libsss_sudo.so #3 0x00007f9fed3837b7 in sudo_sss_result_get (nss=nss@entry=0x7f9fed5ae480 <sudo_nss_sss>, pw=0x7f9ff64b7d28, state=state@entry=0x7fffd6a8dd84) at ./sssd.c:619 #4 0x00007f9fed384eee in sudo_sss_lookup (nss=0x7f9fed5ae480 <sudo_nss_sss>, ret=96, pwflag=0) at ./sssd.c:857 #5 0x00007f9fed37bd1a in sudoers_policy_main (argc=argc@entry=1, argv=argv@entry=0x7fffd6a8e200, pwflag=pwflag@entry=0, env_add=env_add@entry=0x7f9ff64ad570, command_infop=command_infop@entry=0x7fffd6a8df20, argv_out=argv_out@entry=0x7fffd6a8df28, user_env_out=user_env_out@entry=0x7fffd6a8df30) at ./sudoers.c:393 #6 0x00007f9fed37d48c in sudoers_policy_check (argc=1, argv=0x7fffd6a8e200, env_add=0x7f9ff64ad570, command_infop=0x7fffd6a8df20, argv_out=0x7fffd6a8df28, user_env_out=0x7fffd6a8df30) at ./sudoers.c:746 #7 0x00007f9ff56d6ae2 in main ()
Created attachment 694005 [details] ldap.conf
Created attachment 694006 [details] nsswitch.conf
Created attachment 694007 [details] /etc/pam.d/sudo
Created attachment 694008 [details] /etc/pam.d/system-auth
Created attachment 694012 [details] sssd.conf
(In reply to comment #5) > Created attachment 694012 [details] > sssd.conf You seem to have attached the wrong file by accident, that's the ldap.conf file again.
I just ran a quick test with git HEAD (not too far from 1.9.4 at this point) with sudo rules stored on an LDAP server and did not reproduce the bug you are seeing. So I need some more information to debug the problem further. 1) When you started the SSSD, was it already offline? 2) can you put "debug_level=10" into the [sudo] and [domain/$NAME] sections of sssd.conf, restart the SSSD, re-run the test and include the files /var/log/sssd/sssd_sudo.log and /var/log/sssd/sssd_$name.log ? 3) can you install the ldb-tools package and then run: # ldbsearch -H /var/lib/sss/db/cache_$name.ldb 'objectClass=sudoRule' Does this command print any cached rules? Hopefully this should be enough information to see what the problem might be. Thank you!
Also please include /var/log/secure (the entries added during the sudo attempt are enough)
Hi, any luck getting the information we need?
Created attachment 697336 [details] sssd.conf
I just updated to the latest sssd packages and the problem went away. This is strange, because I have been keeping well up to date, and the only change to the package is to rebuild for the latest libldb. Maybe that did it. If I see the problem again, then I will reopen this bug with more information.