Bug 908399 - Sudo stopped working with sssd after update to Fedora 18
Sudo stopped working with sssd after update to Fedora 18
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-06 10:46 EST by W. Michael Petullo
Modified: 2013-02-14 14:01 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-14 14:01:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ldap.conf (109 bytes, text/plain)
2013-02-06 10:49 EST, W. Michael Petullo
no flags Details
nsswitch.conf (384 bytes, text/plain)
2013-02-06 10:50 EST, W. Michael Petullo
no flags Details
/etc/pam.d/sudo (202 bytes, text/plain)
2013-02-06 10:54 EST, W. Michael Petullo
no flags Details
/etc/pam.d/system-auth (1.02 KB, text/plain)
2013-02-06 10:54 EST, W. Michael Petullo
no flags Details
sssd.conf (109 bytes, text/plain)
2013-02-06 10:58 EST, W. Michael Petullo
no flags Details
sssd.conf (574 bytes, text/plain)
2013-02-14 13:53 EST, W. Michael Petullo
no flags Details

  None (edit)
Description W. Michael Petullo 2013-02-06 10:46:33 EST
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 ()
Comment 1 W. Michael Petullo 2013-02-06 10:49:49 EST
Created attachment 694005 [details]
ldap.conf
Comment 2 W. Michael Petullo 2013-02-06 10:50:25 EST
Created attachment 694006 [details]
nsswitch.conf
Comment 3 W. Michael Petullo 2013-02-06 10:54:02 EST
Created attachment 694007 [details]
/etc/pam.d/sudo
Comment 4 W. Michael Petullo 2013-02-06 10:54:39 EST
Created attachment 694008 [details]
/etc/pam.d/system-auth
Comment 5 W. Michael Petullo 2013-02-06 10:58:51 EST
Created attachment 694012 [details]
sssd.conf
Comment 6 Jakub Hrozek 2013-02-06 15:18:38 EST
(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.
Comment 7 Jakub Hrozek 2013-02-06 15:50:27 EST
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!
Comment 8 Jakub Hrozek 2013-02-07 13:45:54 EST
Also please include /var/log/secure (the entries added during the sudo attempt are enough)
Comment 9 Jakub Hrozek 2013-02-14 13:46:48 EST
Hi, any luck getting the information we need?
Comment 10 W. Michael Petullo 2013-02-14 13:53:28 EST
Created attachment 697336 [details]
sssd.conf
Comment 11 W. Michael Petullo 2013-02-14 14:01:27 EST
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.

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